People ("even software people") still use construction metaphor to explain why we need fixed price contracts etc. They seem to forget the fact that even if construction engineering has about 6000 years of history data to help in estimation, big construction efforts still are finished late and the total costs grow way beyond original budget. When you talk about construction, the design cost are negligible compared to actual construction costs and it makes a lot of sense to do the up front planning as well as possible. Changing foundations after building few floors is not possible. Can you imagine building a bridge half way through and then deciding that you need to make it wider to accommodate rails for trains.
Software is different. It's becoming the norm to talk about emergent design, which means that software design is not done up front, but it emerges little by little. I know this one phrase explanation does not cut it and there are people who give actual talks about emergent design, but it's out of scope for this blog post.
In software engineering it's very common to start building something and end up with something completely different. Needs change, understanding evolves and requirements change.
"Only constant is change"The famous quote by Heraclitus is very true at least considering software development. In software development construction costs are non issue and it's worth building as much as possible. Sometimes you just end up doing the wrong thing and that can't really be helped.
"I didn't fail, I found 10 000 ways that don't work"That is very agile mindset really shines. Sometimes you just can't prepare and you end up building the wrong thing. In those cases failing fast is a lot better than failing slow. Taking a cue from Edison, what I really want to say is that you want is make software that don't work fast enough so that you still have time to build the right thing. Eventually you'll get it right.
In software you want feedback. It something doesn't work - great, now we know, we have some information. Now it is up to us to decide what we want to do about it. Faster the feedback loop the better, but you still you need to validate the feedback. Keep in mind that comments from actual end-users are the most important kind. How can you add value, if you don't know who the people gaining that value are.
So with that being said, it time to give our respects to old and dated metaphor. May you rust in peace, you just don't have a place in modern day software development.
