Software's Classic Mistakes--2008

Luis said:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

thank you for nice post

daviddaly said:

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:

thank you for nice post