On February 1, 2006 I'll be speaking at the Atlanta CFUG (www.acfug.org) on static v. dynamic typing and why I think so many of us are missing the power in CFCs. So many of the "best practices" recommended for CFCs are indeed best practices -- for Java. But applying these to ColdFusion often leads to frustration and failure. If you'll be in the Atlanta area on February 1, I hope you'll join me and other developers as we re-examine CFCs.

Thanks to the indefatigable Ray Camden, there is now a forums set up to discuss ideas brought up by my monthly newsletter. The URL is http://ray.camdenfamily.com/forums/threads.cfm?forumid=68396328-A2A1-BC2A-B86644B4B7B0A633. Hope to see you there.

Several developers have made top ten CF posts for this year, including Rob Brooks-Bilson (http://www.brooks-bilson.com/blogs/rob/index.cfm/2005/12/23/The-Top-ColdFusion-Blog-Posts-of-2005). Rather than repeating links to such excellent CF bloggers as Sean Corfield, Ray Camden, Joe Rinehart, Dave Ross, Barney Boisvert, Matt Woodward, Jared Rypka-Hauer, Chris Scott, Dave Shuck, and, of course, Rob himself, I thought I'd offer ten of my favorite blog entries on software-related issues, rather than ColdFusion-specific. Although most of these are blogs, some are interviews and others are articles. In no particular order, they are...

1. Martin Fowler on humane interfaces(http://martinfowler.com/bliki/HumaneInterface.html). Martin is a highly respected writer on software architecture and design patterns. In this post, he talks about the need to create APIs that are human-centric.

2. Bill Venner's interview with Erich Gamma (http://www.artima.com/lejava/articles/patterns_practice.html). Erich is one of the "Gang of Four" who introduced the programming world to design patterns. In this interview, he discusses the intentions and tradeoffs of design patterns.

3. Joel Spolsky's insightful discussion into "making code look wrong" (http://www.joelonsoftware.com/articles/Wrong.html) and a brilliant defense (at least it convinced me!) of the value of Hungarian notation.

4. Meilir Page Jones "The Seven Stages of Expertise in Software Engineering" (http://www.waysys.com/ws_content_al_sse.html). This is so brilliant and so funny that I cannot imagine anyone reading this without getting a great deal out of it.

5. Nathaniel Talbott's thoughts on software, the Long Tail, and Ruby on Rails(http://blog.talbott.ws/pages/the_railroad_then_and_now.html).

6. Dion Hinchcliffe's "Best Web 2.0 Software of 2005" blog definitely deserves a read(http://web2.wsj2.com/the_best_web_20_software_of_2005.htm).

7. Paul Graham's "The One Hundred Year Language" is actually from last year, but it's so good, I had to include it(http://www.paulgraham.com/hundred.html). In this article, Paul talks about the evolution of and outlook for computer languages.

8. Ward Cunningham's discussion of simplicity with Bill Venners (http://www.artima.com/intv/simplest.html) is powerful stuff -- and sets right a misconception about one part of XP.

9. Daniel Read's "Specialties and Strategies" (http://www.developerdotstar.com/mag/articles/read_strategies1.html) on making choices in your programming career is very good.

10. My last choice is Martin Fowler's discussion of type safety (http://martinfowler.com/bliki/DynamicTyping.html) , a very important topic to ColdFusion developers.

 

Have you ever found yourself needing to create tutorials or training materials to help others with a new concept? Oddly enough, sometimes the more you know, the worse of a teacher you are.

The problem occurs because we don't understand well enough how people learn. We tend to think that knowledge is a continuum, where the expert simply knows more than the novice. But there is a much greater divide between expert and novice than the acquisition of facts. The expert has something the novice lacks: a theory. By theory, I mean something like what scientists mean when they talk about a theory (as in the theory of gravitation): a logically self-consistent model or framework into which facts fit. The expert has this; the novice does not.

Perhaps an example will help. Here is a sequence for you to memorize (the pipe symbols merely separate various sections of the sequence):

C, E, G   |  A, C, E   |   F, A, C   |   G, B, D  |   C, E, G

To the aspiring novice, these are facts s/he must learn. But to the expert in music theory, this is the common musical chord progression of I - vi - IV - V - I. If you happen to be a Beatles fan, this chord progression was the basis for such songs as:

• Please, Mister Postman


• I've Just Seen a Face


• Happiness is a Warm Gun


• This Boy


• A Hard Day's Night

The expert long ago learned the sequence and can recognize it, almost by second nature, when s/he hears it in a song. To the novice, the process is long and tortured and involves counting scales on their fingers.

If I want to change the sequence to this:

C, E, G   |  A, C, E   |   F, A, C   |   G, B, D,F  |   C, E, G

...the expert recognizes that I've exchanged a V chord for a V7 chord; nothing more needs to be said. To the novice, it's back to memorization. The expert acquires and assimilates new facts so quickly because they have a theory into which to fit these facts. The novice lacks this.

One of the greatest challenges for teachers (spanning writers of tutorials to university professors) is helping the novice grasp the theory. But, by virtue of their status as novices, new learners can't easily grasp theory; it remains irritatingly abstract. We see this when students set out to learn something like design patterns. There, the theory is usually presented first. "This is the Command Pattern. It includes an Invoker, a Receiver, an Abstract Comand, and multiple concrete Commands."

Students taught like this can, by sheer dint of hard work, mirror back these facts, but of what practical use are they? How will they use their knowledge when they lack a theory of design patterns into which to fit something like the Command pattern? It's such a challenge for the expert to benefit the novice because the experts has long since passed the frustrating stage of "getting" the theory. As I said, it's second nature.

Faced with this situation, experts too often give up and adopt a "X for Dummies" approach. The experts, frustrated by the different plane the novice is on, settle for teaching students facts. In the programming world, students are taught to type certain commands without any recognition that they are communicating with an artifical intelligence (their software machine). This is the "tips and tricks" method of teaching.

Similarly, faced with this situation, students too often mistake learning for parroting back certain facts or being able to type certain commands. Far from empowering them, students feel that they must have an encyclopedic wealth of facts at their fingertips. They may be aware that these facts exist in fragile relationship to one another, but for many, the theory has never crystalized.

Former Librarian of Congress, Daniel J. Boorstin, put this dilemna perfectly: "The greatest obstacle to discovery is not ignorance--it is the illusion of knowledge." His words point the way for us to write better tutorials, articles, blogs, training materials, etc. Experts need to use their expertise not so much to convey facts as to construct situations that will guide the novice into discovery.

If you want to see a great example of this, look at any of the "Head First" series of books, published by O'Reilly. Their Head First Design Patterns is no "Dummies" book, but it certainly is an unusual one, filled with pictures, puzzles, games, and "interviews" with various design patterns. Closer to home, take a look at Joe Rinehart's "QuickStart" guides to his Model-Glue framework, which he wisely begins with the comforting words of Douglas Adams: "Don't Panic!" Or, finally, read Why the Lucky Stiff's Poignant Guide to Ruby. All these examples eschew jargon, preferring instead to provide small spaces in which learners may make their own discoveries, laying the groundwork for true mastery.

As if ColdFusion wasn't under enough pressure from Java and C#, Ruby (with its accompanying framework, Rails) has garnered enormous buzz within the IT community and support from highly-respected developers. On the surface of it, this is bad news for ColdFusion: more competition. But surface impressions are often wrong and never more so than in the case of Ruby.

Ruby is altering the nature of the debate about custom corporate software -- the kind of software most of us make a living writing. A year ago, the debate centered over J2EE v. .NET: the Battle of the Titans for predominance in the IT space. It's worth noting that both Java and C#, Java's flagship for .NET, are strongly (i.e. statically) typed languages. Indeed, it was argued, only strongly typed languages have the needed rigor to deal with the complexities of IT applications. And then, along came Ruby.

Ruby is dynamically typed and Ruby developers, far from apologizing for the language's lack of support for static typing, revel in it. "What is a type?", they ask. "Why should a type be tied to an inheritance hierarchy -- even if that inheritance is one of specification rather than implementation, as in the case of interfaces?" It's a very good question -- all the more since it was assumed that typing forms the basis for polymorphism in OO languages. But with Ruby's dramatic entry onto the IT scene, we can see that we mistook polymorphism (the ability for different objects to act on the same message in different ways) for type promotion.

Ruby apologists promote "duck typing" as a purer form of polymorphism. "If it walks like a duck, looks like a duck, and quacks like a duck, it's a duck!"  With duck typing, the test for types doesn't require that different objects descend from the same class (or interface) hierarchy, but simply that objects can respond to the same messages. Without the restrictions of static typing, Ruby developers allow classes to borrow methods from other classes (and even individual objects to borrow from other objects) in a mechanism known as "mixins". Dynamic typing promotes object composition over class inheritance.

Ruby has also transformed the debate from one over languages to one about best practices in software engineering. Ruby (and Rails) assume developers will adopt best practices and has built-in support for things like Model-View-Controller architecture and test-driven development. In fact, Ruby takes much of the best from a number of languages including Smalltalk, LISP, Perl, Python. Need to handle regular expressions? No need to download a library or toolkit for this -- Ruby has it built in. The same is true for XML parsing, HTML and FTP, CGI support, database interaction, GTK and Qt bindings and even a pure Ruby BTree library. Paul Graham has persuasively argued that truly impactful languages are not those written for to keep mediocre developers from doing any great harm (think "Ada"), but those that empower the best in the programming community. Ruby certainly fulfills this directive.

"That's great for Ruby," you might say, "but what about ColdFusion?" ColdFusion has long had dynamic typing, rich built-in libraries, and mixin ability. It shares a good deal of what might be termed the "Ruby philosophy". But IT managers have found it safer to insist on Java or .NET. It's not that either of these languages makes developers more productive, but that they are both safe choices. The old dictum, "Nobody ever got fired for buying IBM" had given way to an updated version: "Nobody ever got fired for choosing J2EE or .NET".

Managers are often a very risk-adverse lot. I have spoken with many managers who "knew" that Java and .NET were far superior to humble ColdFusion, although they had nothing but talking points from Sun or Microsoft to support their decisions. With Ruby's success in the IT world, managers may find the safety to re-examine their assumptions. It's up to us to help them see that ColdFusion can play a significant role in re-invigorating web development as we haltingly make our way to the Web 2.0.

 

Jeff Peters and I have started a podcast. Each week, we'll spend 30 mins or so talking about software issues. The first podcast is available at helmsandpeters.com. Hope you enjoy it.

I'm reading a book recommended by one of my newsletter readers: Emotional Design: Why We Love (Or Hate) Everyday Things. Written by Donald Norman (of The Psychology of Everyday Things fame), the book explores why usability alone isn't enough. Norman argues that we appreciate things on three levels: visceral, behavioral, and reflective.

Visceral attraction is that which we feel for a Ferrari or an iPod. It's beautiful and we want to sit in it (Ferrari) or touch it (iPod). Behavioral attraction is the appreciation for something that works very well. The word we often used to describe it is "intuitive". Finally, reflective attraction is about meaning and self-image.

Norman argues that great design incorporates all three aspects and produces things we love. He even argues that well-designed objects make us work better. I won't try to explain his thinking, but his arguments did get me to think about something I've talked a lot about: prototypes.

In the design world, prototypes are an absolute necessity. When the designer of the original Palm Pilot was working on a design, he carried a block of wood around in his pocket. What was comfortable? What felt too big? Too small? Were the buttons right?

And yet, for some reason, many developers feel that "design" is something best left to graphics artists. But when I talk about the necessity for prototypes, it's not just look and feel that I'm stressing, but rather that the very act of using something reveals what we want from that thing. Until I see the iPod's spin-wheel, I don't know that I want it at all. It's no good asking me for "requirements". If I knew that, I could just hire a 16-year old programmer.

I believe that in almost all cases of business software, working without prototypes entails great (and needless) risk to both developer and client. Requirements documents may be useful for lawyers, but they have limited usefulness to us. Prototypes allow us to try out new ideas and see how users react to them. They give us the freedom to explore the visceral and behavioral aspects of design--and maybe even the reflective.

I've been using prototypes for quite a while. My first explorations with them was constrained to exploring behavioral issues. "Don't worry about the look and feel," I would tell clients. But they would worry about the look and feel. I finally realized that until I took care of this need of the client--no matter how secondary in importance it seemed to me--we simply couldn't move on to the issues that were of great concern to me: how the application needed to behave.

Years ago, Abraham Maslow arrived at his "Hierarchy of Needs" for individuals.

1. Physical survival: water, food, sleep, shelter...
2. Safety and security: physical safety, economic security, comfort...
3. Social needs/belonging: acceptance, group membership, love, affection...
4. Self-esteem: recognition of mastery, prestige, status...
5. Self-actualization: innovation, creativity, deep learning...

Until a lower-level need was satisfied, Maslow argued, people couldn't attain satisfaction of needs higher up the hierarchy. The problem with starting with requirements documents, flowcharts, UML diagrams and the like is that these don't deal with the client's basic concerns: what will this look and feel like? What will it be like to work with?

Prototypes answer those questions and allow us to introduce ideas and get feedback from clients in ways that words simply cannot. They give us a common langugage that has a specificity and concreteness to it that words lack. I believe that great applications--like other great designs--must incorporate visceral, behavioral, and reflective appeal and I can think of no better way to begin the process than with a thorough, comprehensive prototype.