The big software projects I’ve seen go bad don’t feel analogous to the bridge failure mentioned in the article. It’s more often poor project management, unclear requirements, and sub-par communication rather than a specific engineering failure.
Despite the lack of public post-mortems, poor project management seems to be widely recognized as a problem. But there isn’t a clear cut solution. Agile promised to save us all but seems to be implemented poorly more often than not.
Agile (of the scrummy, we just meet sprint goals that we set type) is not a project management solution, it is saying “well this seems hard, so we’re not going to do it”.
Project management is happily alive. Thinking Agile in some way solves project management is insane.
Plan out your system, estimate the time to build it (you don’t even need good estimates), execute ruthless change control. It’s not hard, just takes discipline. Ruthless change control is the hard part. That doesn’t mean saying no, it means saying “if you change things, it costs you schedule days”.
If you want a clear cut system, iDesign has some good classes. Imo at least.
> “if you change things, it costs you schedule days”.
When I worked for Philips as a test hardware design engineer in the old Mullard Radio Valve plant in the late 70s and early 80s (a major semiconductor plant despite its name) we were even stricter than that. Every project started with a rough estimate for the total cost, we then spent 10 percent of that on a combination of prototypes and a better estimate of the time and cost and refinement of the requirements. The customer department would then decide whether to proceed. At that point the requirements were frozen. Our department was then committed to the project schedule and price and the customer was committed to the requirements. Any changes would require exactly the same procedure as before: rough estimate, 10 percent preliminary study, better requirements and plan, commitment, development, delivery.
Part of the purpose of this was that at the end of the ten percent phase the customer could take his requirements to an external supplier (British Aerospace for instance) and get a quote from them instead and possibly actually give them the job.
What is “ruthless change control”? If it means placing realistic constraints on how sales or customer relations teams can alter deadlines, priorities or scope of work, then it simply does not exist in corporate IT and is intrinsically disallowed by the inborne organizational structure of modern companies.
Once you finished planning out your system the requirements have likely changed. If they didn't you'll find out that you built something different from what the customer wanted once you're finished programming.
I don't think you're necessarily disagreeing with the parent post.
> Ruthless change control is the hard part. That doesn’t mean saying no, it means saying “if you change things, it costs you schedule days”.
Just because software is dominated by soft costs doesn't mean that it's cheap to change requirements. That doesn't mean you can't deviate from your initial spec, it just means you have to charge the customer for changes that they want after you've already started development. Throwing away work just because it's "easy" to change software doesn't magically recover the time and money that you're already spent up to that point.
Despite the lack of public post-mortems, poor project management seems to be widely recognized as a problem. But there isn’t a clear cut solution. Agile promised to save us all but seems to be implemented poorly more often than not.