Comments on the Legislative Audit Bureau report

Posted by Robert Merrill on November 22, 2008 under Uncategorized | Be the First to Comment

(I wrote this back in Summer 2007, but since I went all WordPress all the time, I had to recreate it as a blog post and the date changed).

Nothing I read in Report 07-5 surprised me at all. The problems are well known.

• Big projects are failure-prone
• Requirements are hard to understand, and they change with time
• Early lifecycle estimates aren’t very accurate
• Pre-existing data is messy
• Pre-existing software is messy

None of these things surprise or frustrate me any more. Nor do I expect they surprise most software-development professionals.

What frustrates me are the proposed remedies.

• Better planning
• More oversight

Like the problems,they don’t surprise me. To quote the American novelist Willa Cather, “There are only two or three human stories, but they go on repeating themselves as fiercely as if they had never happened before.” Calls for better planning and more oversight don’t surprise me. They just frustrate me.

The first one is less frustrating. I’m not against planning. I do it all the time. It helps me focus on the objective, gather my thoughts, and take the first few steps with confidence. But plans do not determine the future. The future just isn’t very cooperative.

The second one frustrates me more. Apparently, Kate Nolan had plenty of oversight. On the same day that the Wisconsin State Journal reported on the audit findings, it also reported that Ms. Nolan, a project manager on one of the few large projects praised by the audit, was taking early retirement because she was “very, very tired” of fighting “patently ridiculous ideas” from superiors. By and large, software projects don’t need more oversight. They need better oversight. Overseers need to find the trustworthy and the competent like Ms. Nolan, listen to them, and empower them, not burn them out and run them off. And they need to understand and accept that

• Big projects are failure-prone
• Requirements are hard to understand, and they change with time
• Early lifecycle estimates aren’t very accurate
• Pre-existing data is messy
• Pre-existing software is messy

You can succeed despite these things, but only if your recipe and criteria for success don’t depend on their not being true.

Learn More

Software project success, failure, estimation, and methodology are fascinating topics, and it’s surprising how little people who ought to know about them, don’t. Here are my top picks:

Lean Software Development: An Agile Toolkit by Mary Poppendieck. Lean manufacturing and product development (think Toyota) applied to software, by someone who’s actually done both software and product development. It’s even a short book!

Software Estimation: Demystifying the Black Art by Steve McConnell. Chapters 8 and 9 of Steve’s Rapid Development are also an excellent introduction to the estimation problem.