Digital Edition

SYS-CON.TV
Unnatural Acts
Unnatural Acts

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.

About Hal Helms
Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1



ADS BY GOOGLE
Subscribe to the World's Most Powerful Newsletters

ADS BY GOOGLE

In this presentation, you will learn first hand what works and what doesn't while architecting and d...
Everyone wants the rainbow - reduced IT costs, scalability, continuity, flexibility, manageability, ...
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 20...
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT...
SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 1...
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with e...
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point wh...
Dynatrace is an application performance management software company with products for the informatio...
Today, we have more data to manage than ever. We also have better algorithms that help us access our...
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held Novemb...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: D...
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22...
DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, ...
SYS-CON Events announced today that IoT Global Network has been named “Media Sponsor” of SYS-CON's @...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018,...
DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing w...
Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear...
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news an...
Enterprises are striving to become digital businesses for differentiated innovation and customer-cen...
DXWorldEXPO LLC announced today that Telecom Reseller has been named "Media Sponsor" of CloudEXPO | ...