GAO preaches on software development model

GAO preaches on software development model: "By contrast Motorola, as well as other large commercial companies, spend just a few percent of its budget on rework.

This huge difference, according to Carol Mebane and Cheryl Andrew of the Government Accountability Office’s weapons acquisition audits practice, is based on a structured, replicable approach to software development that emphasizes requirements planning upfront. Three years ago Mebane and Andrew spent months studying how commercial best practices could be applied to DOD projects to control both cost factors and schedule slippages. "

There's some good and some bad in here. First off- weapons acquisition is a little different than software acquisition, even when it's software that runs on weapons. Second- WTF is it that makes everyone think they can magically figure out all of the requirements for their software before they try anything to see what works? Maybe these two geniuses should read the IEEE Computer paper about Motorola's experience with Agile Software Development practices. Or about their Agile approach to Six Sigma?

"Get all of the requirements right before you do any work"- this is a fake solution to avoiding rework. Sure, you can control schedule slippages if you build exactly to the requirements, with the general problem being that you end up building what the requirements said, and not what was needed. Requirements change. Adapt to that fact of the world, don't try to change the world to make requirements static. You will lose.

Fortunately, this crack GAO team has realized that most DoD projects are way too long. "Creating a manageable environment means breaking software projects into manageable pieces, each generally with a six-month schedule." But then it gets scary:
“Based on our discussions with individual [companies], three factors determine” the success of a software development program, Andrew said. “A manageable environment, disciplined processes, and metrics, metrics, metrics.” First of all, that's 5 factors ;-), I like the first two, but what metrics do they mean? If the start measuring delivered, working code- okay. If they measure lines of code or design documents created- I'd be a little worried. (and yes, most CMMI processes I have seen measure productivity or progress in terms of pages of design/requirements documentation)

Well, I am glad to see the government taking some steps to save us money on bloated software development projects: Shorter project cycles- good, all requirements up front- highly questionable, metrics- dangerously vague!