Most Read This Week
By: Hal Helms
Nov. 11, 2003 11:09 AM
Ah, television! Where else can you see so much action? Murders are routinely committed and solved, dastardly plots are hatched and foiled, and characters learn some deep life-truth - all within a single hour.
This makes the runaway success of ESPN's "World Series of Poker" and the Travel Channel's "World Poker Tour" all the more mysterious. What is it about a group of middleaged men, 11.5-gram clay chips, and 52 brightly colored cards gathered about a large felt-covered table that's so appealing to so many?
When I was in a bookstore recently looking for books on poker, the sales clerk looked at me knowingly as I made my purchase. "We've been selling a lot of those," she told me. "Do you watch the games on TV?" I admitted I had.
While many people have played "Wednesday night poker" with friends for years, I've been a latecomer to it. Feeling slightly guilty for the years of poker I had missed out on, I decided to plunge into it. The rules are simple enough; surely a bit of poker knowledge would lead me to success.
I was fortunate enough to have two students who are excellent poker players and who recently attended classes I held in Las Vegas. During the day, I taught them about successful programming; during the night, they taught me about successful card playing.
One of the lessons I found hardest to learn was that successful poker players don't passively accept ("call") other people's bets; they take the aggressive act of initiating and raising bets. "If a [card] hand is good enough to call," one player told me, "it's good enough to raise."
"But," I protested, "it just doesn't feel natural." My student-cum-teacher looked at me curiously. "Of course it's not natural. What's natural is losing."
This truth must have been slowly seeping in, for I found myself thinking about programming in light of this. Albert Einstein once remarked that what passed for "common sense" is really the collection of prejudices acquired by the age of 18. According to a 2002 Standish Group report, corporate software projects fail at an astonishing 70% rate. I began to ask myself what prejudices are common to us programmers, and what unnatural acts are called for to avoid the common experience of failure.
Here's a list of seven common practices that lead to failure - along with their remedies.
1. Undervaluing encapsulation: This practice leads to large files with a great many lines of code. A single file then has many responsibilities. I once worked with a programmer who showed me (proudly) an application that consisted of a single file with 12,000 lines of code. When we practice encapsulation, we break the application into many small, discrete pieces, each of which is responsible for doing only a small bit of work. A well-defined interface specifies what the code requires and what it will provide. The greatest single reason for object-oriented programming's success is the powerful abilities it provides programmers to practice encapsulation. ColdFusion components (CFCs) allow us to build highly encapsulated components whose interface we can examine with the excellent component browser provided with ColdFusion MX. A wellencapsulated application then resembles nothing so much as a conversation between components.
2. Testing later: Here, I'm being charitable. Often, of course, no testing is done; we rely on our users to do the testing for us. The reason for this practice is, I think, that while we know we should test our software, we may not know exactly how to go about this. Testing is not something that should be done later. We should treat writing code and writing tests for that code as two parts of a whole: one isn't done without the other. Kent Beck, of Extreme Programming fame, has written an excellent book entitled Test-Driven Development, which provides clear guidance on how to approach software by writing the tests before the code is written.
3. Cowboy coding: In this practice, the myth of "rugged individualism" is applied to the practice of writing code. Each programmer heads out into the sunset on his or her own horse, determining an individual course of action. Pair programming? Code reviews? Not out here in the Wild West where such sissified acts are objects of scorn to real men (and, sadly, women). Put several cowboys together and you don't have a team - you have the potential for a shoot-out. It's ironic that the same personality that often leads to excellent acts of individual programming spells disaster when a project is too large or its lifespan is too long for a single individual. The remedy for this malady is stiff medicine: the programmer must actively work to create an environment in which others are involved and consulted. Talk about an unnatural act!
4. Omitting prototypes: In his terrific book, Code Complete, Steve McConnell provides clear statistics that show that the greatest single action we can take to guarantee a successful software project is prototyping. Prototyping goes far beyond simple mock-ups; a complete prototype should make the user think that he or she is seeing the actual software. If we create the "front end" of our software first, we have the greatest chance of success with actual users - the only valid judges of our success or failure. Why is this so important? Simply because to the users, the front end is the application; they take it for granted that "all that back-end stuff" will work. Seem odd? Well, as Alan Cooper points out, when was the last time you bought a phone and demanded to hear the dial tone before purchasing it? Didn't you take it for granted that "all that phone stuff" would work correctly?
5. Not defining acceptance tests: By what metric do we judge success? If we have no predefined acceptance tests, how can we know that we've succeeded, or that we're even done? For too many, an "acceptance test" consists of asking the client, "Do you like it?" That question - do you like it? - is enormously important. It's so important that it needs to be placed in the context of the prototype where clients can go through the iterative process of finding out exactly what they want in a safe environment. Acceptance tests should be a formal, measurable way of simply ensuring that the approved prototype runs. Acceptance tests should be established prior to the start of coding and should define both the procedures and the hardware on which tests will be run.
6. Not using a framework: The history of programming can be seen as a series of greater and greater abstractions. ColdFusion's popularity is due in large part to its ability to abstract lower-level functionality into tags. Oddly, though, some programmers stop here: each application is built as if it were the first and only application. As is the next application and the next. Frameworks provide a foundation on which you can build your own applications. One of the great benefits of both abstraction and frameworks is that they require less low-level work, giving you the time and freedom to work on making your app truly great. The downside of frameworks is that to become proficient, you must learn the framework. Luckily, popular frameworks such as Fusebox 4 and Mach-II have active communities that are quick to offer help, and books and training exist to advance your expertise.
7. Shallow learning: Rene Magritte, the Belgian surrealist painter, once painted a large pipe on a canvas, with words underneath proclaiming, "This is not a pipe." Magritte's point was that an image is not the thing itself. I sometimes think that all buzzwords should be accompanied by a sign proclaiming, "This is not an idea." The culture of programming is "dumbed down" when we rely on TLAs (three-letter acronyms!) and buzzwords to take the place of a deep understanding. There is indeed an overwhelming amount to learn in our business, and each day our present knowledge becomes worth less as it edges toward obsolescence. I wish I had a great remedy for this, but I know of none.
Instead, we must have the courage to admit that continuous learning is an absolute requisite for us and do all in our power to deepen our understanding by reading, experimenting, and attending training classes and conferences. The problem with buzzwords is that they short-circuit this admittedly difficult process, tricking users into thinking that they have already attained knowledge. This illusion of knowledge is intellectual quicksand that will undermine our efforts far more profoundly than simple ignorance.
Some unknown wit once remarked that insanity is defined as "doing the same thing over and over - while expecting different results." We all want to excel at what we do, but unless we've arrived at the pinnacle of our craft, we're going to have to step out of our comfort zone and perform a few unnatural acts to get there.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters