Software's Classic Mistakes--2008

  1. Posted on May 13, 2008 11:43:AM by Steve McConnell to 10x Software Development
  2. Management, classic mistakes, white paper, survey, Articles

In 2007 my colleagues at Construx Software and I updated the list of classic mistakes from my 1996 book Rapid Development. Throughout 2007 we conducted a survey to determine the frequency and severity of these classic mistakes. In other words, we wanted to get a more quantitative sense of just how "classic" these classic mistakes are.

More than 500 people responded to the survey. The majority of them were involved with web and business systems. A significant minority were involved in shrink wrap/commercial systems, and about 10% were involved in embedded, system critical, systems, SaaS, or other kinds of software. About half the respondents were in lead/architect roles, about one-quarter in individual technical contributor roles, and the rest were in management or dual management/technical roles. The results are available in a white paper, " Software Development's Classic Mistakes 2008." You will need a login our main web site to download the white paper. (The log in is free.)

Excerpts from the Classic Mistakes Survey

Based on the survey responses, we computed the approximate frequency of the mistakes surveyed. Here is an excerpt from the white paper that shows the approximate frequency of occurrence of the most common classic mistakes:

approximate frequency of classic mistakes

We also examined how severe the mistakes are when they occur. This excerpt from the white paper describes which mistakes produce Catastrophic or Serious consequences the most often:

image

Finally, we made an assessment of which classic mistakes are most damaging overall. We multiplied the approximate average frequency of each mistake times its average severity to arrive at a Mistake Exposure Index (MEI). The MEI ranges from 0 to 10, with 10 being the worst. Here is an excerpt from the white paper that shows the classic mistakes with the worst MEIs:

image

Here is an excerpt that summarizes the average frequency and average severity of the mistakes with the highest MEIs:

image

Conclusions from the Classic Mistakes Survey

The raw survey results are interesting and so are some of the general trends.

One conclusion is that two of the mistakes added in 2008 (i.e., that weren't in my 1996 book Rapid Development) made the top 10:

  • Confusing estimates with targets
  • Excessive multi-tasking

This suggests that continued refinement of the classic mistakes list is worthwhile.

A second conclusion is that a few of the mistakes don't occur frequently enough or aren't severe enough when they do occur to really be considered "classic" mistakes:

A third conclusion is that many of the mistakes in the survey do indeed deserve to be called "classic" mistakes. I find it interesting that 8 of the top 10 mistakes in this year's report were listed in a book I published in 1996. If these mistakes were classic in 1996, they're even more classic 12 years later!

Final Thoughts

We'll be updating the classic mistakes survey in 2009, and we'd appreciate your input into the survey. You can take the survey in about 30 minutes. If you take the survey, we'll send you the results before they're made available to the general public.

Why do people keep making these mistakes? I'm interested to hear your thoughts.

Resources

Luis said:

May 13, 2008 8:59:PM

Thanks for making this information public.  Why do people keep making these mistakes?  It would take a Ph.D. in Psychology to really answer this.  However, I have one theory.  We all have a risk threshold we're willing to tolerate.  In some cases, we will actually add risk to a low risk situation in order to reach that threshold.  For example, studies have shown that people who, by law, must wear seat belts (i.e. lower their risk), will drive a little faster, a little more aggressively, etc. until they reach their personal level of risk comfort.

I think this natural human characteristic comes into play when people manage software projects.  In addition, I think there is a fundamental lack of education in basic topics like estimation, project management and even client management.  

Jan said:

May 14, 2008 4:32:AM

I think a lot of problems stem from the invisible nature of software. Nothing can measure the progress of software except usage; unlike a building which gets bigger or a bridge which gets longer.

Since most software progress information is a proxy for the real thing it has far greater error baked into it. And yet it's treated with the same levels of confidence as progress of physical construction.

Paul said:

May 14, 2008 12:53:PM

Thanks for sharing the classics!

Estimating is a professional skill. Developing it requires training, good coaching & practice. There's no substitute for experience, performance data & lessons learned. In addition, the ability to communicate to management (& other stakeholders) in their language is essential.

If you're a technology expert, amateur estimator, no historical data & lessons learned to support you -- and don't know how to tell your story in others language -- you'll need a lot of luck and a very forgiving manager.

Mark said:

May 14, 2008 7:27:PM

If I have to hear one more person tell me that they're really good at multi-tasking and that they're "just as productive doing more than one thing at once"... or worse... "that they get more done that way", I'm going to lose it.

Meanwhile, the dates just keep sliding on by.

John Rutter said:

May 15, 2008 6:19:AM

Interesting figures, but I wonder about the ranking if 'noisy, overcrowded offices' came out above 'abandoning planning under pressure'.

Maybe there are some office conditions out there that are *really bad* :-o

Steve McConnell said:

May 15, 2008 9:31:AM

John, The reason "noisy crowded offices" came out higher than "abanding planning" is that it was found to be more common. As the summary table says, abandoning planning is more serious when it occurs--it just doesn't occur as often.

Maksym Shostak said:

May 17, 2008 2:42:PM

Maybe, people keep making these mistakes because they don't know about them. If they do know, they don't know recipes to avoid the mistakes.

Are there classic recommendations to eliminate these issues?

Abhi said:

May 18, 2008 12:05:PM

As a project manager, I never abandon planning because I realize that the project plan created at the outset is only the best case scenario plan and it may need to be changed at any given moment.

Andy said:

May 22, 2008 9:50:AM

I think a combination of the invisible nature of software, and the idea that software development is an art, not engineering. If the focus was on engineering, learning best practices, and educating the workforce on topics like estimation, project management and SDLC, would be more common. It still seems to be isolated, companies doing/learning all on their own. You don't see construction companies figuring out how to build buildings or bridges on their own. Which ties into Maksym's comment, when learning on your own, its hard to figure out how to avoid classic mistakes.

Ali Kitabi said:

May 22, 2008 11:45:PM

Thanks for sharing the information.

I think that most of the risks indicated can be handled at while working in a software firm, however when working in a corporate sector you are cramped up by the upper management pressure who are not so savvy about the software development risks. You always have less time therefore you need to balance out your variables from Product/Quality/Cost. Of which most of the time quality has to stand aside.

Earl Beede said:

May 23, 2008 8:19:AM

I've passed along other articles by Steve to the rest of my department - often getting spirited debate ("Technical Debt" was highly regarded).

"Software's Classic Mistakes - 2008" was met with silence.  I had to check with a co-worker to make sure the email actually made it through.  I think we've got some elephants in the room that nobody wants to talk about.

Astonishing.

ravinder said:

May 29, 2008 1:26:AM

thank you for nice post

daviddaly said:

June 4, 2008 3:55:PM

Thanks for another great post!

It is difficult to know why the same mistakes continue to be made. Possible theories that I have include:

Long learning cycles – because many software projects are long few people experience enough of them in their career to learn all the required lessons.

Blaming other people – all too often people, teams and companies blame someone or something else for project failure, an attitude that hinders learning and improvement.

Post rationalisation – no matter how badly a project goes people look back and think “we did the best we could” which again prevents them from learning effective lessons

A lack of time for reflection – it is only possible to learn from mistakes if you take the time to properly reflect on and evaluate how a project went.

I have gone into a little more detail on my blog post about this at outofthetriangle.wordpress.com/.../do-we-learn-from-our-mistakes

ravinder said:

June 5, 2008 4:23:AM

thank you for nice post

Post a Comment:

 
 

Steve McConnell

Steve McConnell is CEO and Chief Software Engineer at Construx Software where he consults to a broad range of industries, teaches seminars, and oversees Construx’s software development practices. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds.

Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His books twice won Software Development magazine's Jolt Excellence award for outstanding software development book of the year.

Steve has served as Editor in Chief of IEEE Software magazine, on the Panel of Experts of the SWEBOK project, and as Chair of the IEEE Computer Society’s Professional Practices Committee.

Steve received a Bachelor’s degree from Whitman College, graduating Magna Cum Laud, Phi Beta Kappa, and earned a Master’s degree in software engineering from Seattle University.
Contact Steve