More from Karl Weigers

Karl Weigers, the author several books and articles on software requirements, has written another article found via a link on Dr. Dobbs.

It's more good advice, but as one of the commenters noted, it's advice that Weigers and others have been espousing for years, and I don't know about the dedicated software shops, but I know most IT shops are still missing the mark.

It's also interesting to note that Weigers talks about getting as much as you can right from the start, and of course it didn't take long for an agilist or two to point a finger and yell, "Waterfall!". Weigers tries to tell those posters that he didn't say "all the requirements have to be up front" but that there needs to be a solid foundation before people start hacking out code. But I don't think he needs to apologize for anything he said. Even Joel Spolsky has said he's been successful with BDUF.

Of course both sides have a point; it is also not wrong to prototype quickly (although in impatient organizations there is the danger developers will be told, "Oh, that looks good, put that prototype into production.") But how much of the requirements should be done up front? I think the severity of the cost of failure should have a play in how much needs to be done up front; if you're building the Saturn V rocket program for the Apollo space mission, or the F-15E Strike Eagle program, or medical systems software, damn it, you'd better have your ducks in a row up front or it's going to mean lost lives.

If you're a one-person team making a fairly simple card game as freeware on your own time, well, by all means, start hacking.

Somewhere in between those extreme examples are these silly things called multi-billion dollar companies that use software for everything from accounting to operations to customer service. I could be a real joker and say that perhaps it's good for the economy that so many corporate systems are broken and need lots of people to support them. But if you're one of the people stuck supporting broken systems, you might not find it funny as you spin your wheels trying to read arcane and undocumented hieroglyphics and wishing that you could be working instead on a new feature that would open up new options for the sales department.

Bad software is usually a result of poor requirements and it does cost companies more than they realize. But for a lot of them, the cost of failure is more payroll in maintenance and customer service...they're loath to pay it but some consider it just another cost of doing business. And if they're willing to pay it, then accept it, keep plugging, and refactor where you can.