in reply to Developer Accountability
How do you explain that two extra weeks of planning now could save us four weeks of change and bug chasing on the back end?
I don't.
After reading Pete McBreen's Software Crafstmanship, I think there's a big difference between the kind of software NASA writes and the kind of software most of the rest of us write.
Yeah, they did make a really really big mistake by not communicating with each other -- but I don't think adopting the rest of their development practices is going to be very effective for business and open source development.
I think the real problem is pretty simple. We're not solving the users' most important needs. The solution to that is also pretty simple. Get your customer involved as soon as possible and keep him involved.
Imagine how much time and effort you could save if you could ask the customer, "What's the most important thing this software could do that we could implement in the next week?" Suppose then you implement it and the customer is right there to say, "Not quite right, just a little different, okay perfect!"
Call that better QA or development lifecycles if you like. I'm just convinced that getting feedback early and often and acting on it all the time is a much better way to write good software than hoping your one-, three-, or six-month-old plan got everything right.
There are lots of ways to handle the rest of the issues -- testing, refactoring, pair programming -- but the way to provide useful, effective software is to be in constant communication with the actual customer.