Software development’s classic mistakes and the role of the CTO/CIO

Here’s a post of a type I rarely do: a reaction to an item recently posted to the Internet. Specifically, a day or two ago, Steve McConnell’s firm Construx, Inc. released their update of McConnell’s list of classic software development mistakes. This survey and its results is worth everyone’s time to read (and ponder) carefully. Their summary of the paper is as follows:

“Classic mistakes are ineffective software development practices that have been chosen so often, by so many projects, with such predictable results that they deserve to be called classic mistakes. Steve McConnell first introduced this concept in Rapid Development in 1996. Construx recently updated McConnell’s original list of classic mistakes and then conducted a survey to assess the prevalence and impact of these mistakes. This white paper shares survey results–both expected and surprising–and analyzes the survey findings.”

The Construx survey results document pretty much speaks for itself, and provides interesting detail that I won’t repeat here. Hence, this is a bit of a “piling on” kind of post, in part because I respect McConnell’s work in the extreme, but also because I want to add some “color” to what he intentionally presents with (relatively speaking) a “just the findings” deadpan dryness.
Here are the top 6 “Worst Mistakes” outlined in the document, taking into account both their frequency of occurrence and the severity of their impact when they do occur:

1. Unrealistic expectations
2. Overly optimistic schedules
3. Shortchanged quality assurance
4. Wishful thinking
5. Confusing estimates with targets
6. Excessive multi-tasking

Needless to say, this list struck me as eerily accurate to what we all experience in IT circles. The thing I find the most astounding about this list is how we keep making the same mistakes over and over again. Despite all the project management lore we’ve all absorbed, despite all the “lessons learned” meetings we’ve all sat through, this list hasn’t (and maybe won’t) change. Why? Here are just a few contributing reasons:

• The systems that stakeholders see and regard as benchmarks (i.e., for functional capability) have evolved in most cases over many years, in terms of functionality, robustness, and elegance. But those systems have set the standard, and set generic expectations. Things seem simple to do once you’ve seen them done, and it’s oh-so-easy to forget how much time and resources it took to get them to “done” status.
• There’s a rising belief in management that schedules (and people’s work intensity) will naturally adapt to fit whatever time is allotted, so why not set a purposely short time to start with, “just to keep the pressure up.”
• Market pressures keep increasing, meaning we all are constantly challenged to get more done, faster, and with fewer resources.
• Stakeholders won’t naturally take a long-term view: they tend to minimize the often extreme down-the-road headaches that result from the cutting of corners necessitated by the rush, rush, rush mentality. They’ll drive the car without ever changing the oil.

But in a nutshell, struggling proactively against the setting of unrealistic expectations and overly optimistic schedules is the brunt of a CTO/CIO’s job. When unrealistic expectations are allowed to persist and prevail anyway, it actually means we’ve failed: failed to educate, failed to take a sufficient stand. It all comes down to leadership. It’s part of the territory. Whether we like it or not.

Actually, more often than not, I think that stakeholders secretly expect to have their expectations reined in. My shortcut slogan for doing this is, “I can’t be in New York in an hour.” (Note that I’m based in Seattle). If you somehow have the expectation (hope, desire, etc.) that we’ll be able to be in New York in an hour, I can’t and won’t sit by and wait for the hour to elapse before I let you in on the disappointment. Taking that kind of shatter-expectations-up-front approach requires spine, verve, fearlessness. It takes the kind of self-confidence that accepts the risk that one will be unfairly labeled as a “no can do” kind of guy/gal.

But that’s why you’re the leader.