| Here is a conversation that could happen building a bridge if the builders were like some developers (aka, not engineers): - "hey, let's figure out the physics of this."
-------> "No, let's build a small bridge here with these Legos. I bet they work" - "ok, let's trace the design key points."
-------> "What for? Let's just start right here, aim more or less over there, and that's it" - "Ok, time to go rent some excavators."
-------> "But why? It takes too much time. I can build an excavator here. Look. There. I just built an excavator" - "Look, they sent us a blue excavator."
-------> "No no no. Excavators must be yellow. Don't like it. Return it." - "Ok, we need to hire extra workers."
-------> "But wait, do they have experience with blue excavators? Yellow only? That's lame. Keep looking" - "Ok, let's put some signage so people know what to do"
-------> "No, let's just see where they go and we will extend the bridge there!" ... and the best one - "Well, we need more resources to finish this project"
-------> "Nah, let's just open source it and forget about it!" sigh |
Software can be built like bridges. But most software doesn't really need that level of attention, so it isn't built like bridges. In a commercial environment, the benefits of the added overhead would have to justify the expense. I would roughly estimate that avionics-style overhead would quadruple the budget and schedule of your typical web or iOS software project. Is it worth it?
Maybe it'd be worth just being a little more strict, even if not four times as strict. Someone has to make those decisions. But it's certainly possible to take software development more seriously.