I this quote:
Software is Concrete. Once poured it becomes extremely difficult and very expensive to change.
It comes from a blog post by Robert Howe, CEO of Verum, a company selling formal-methods-based and model-based programming tools. It does capture something of the phenomenon we all know: that software can be pretty darn hard to change, once it has shipped and is in use. It fits well with the fact that the later bugs are found, the more expensive they are to fix.
But it also provoked quite a bit of opposition when I put the quote up on Facebook, and I have to agree that maybe not all is as simple as that blog makes it out to be.
The main problem as I see it is that it compares the development of software to the construction phase of a bridge (or other civil engineering structure). When software development is really much more like the architecture and exploration work that goes on long before the bridge is starting to be built. The blog post recognizes this in a way, I admit that. But you cannot escape the feeling that the fundamental thinking behind it all is waterfall-based. It never says so, but it feels like that.
Which is a shame – I cannot see that there is any fundamental dichotomy between being iterative, agile, and changing things as requirements clarify, and using model-based development and formal methods. The idea of model-based development is to program at a higher level of abstraction to get more efficiency. And programming at a higher level of abstraction fundamentally supports agile and iterative development, since the amount of “code” you must change is smaller. Model-based development ought to support drastic and quick changes to software just like modern dynamic programming languages and powerful frameworks support it. Add in some model checking to find important classes of bugs (like deadlocks and dead-end states) automatically, and you have a very agile programming environment.
In software development, I don’t think there needs to be a great step from design and architecture to implementation. It seems to be more gradual, you build code as you go along and ideas get more and more detailed, and slowly you get to something fairly concrete and indeed fixed. The trick is to make this process gradual and find issues early, so that they are cheap to fix.
Overall, it seems that software is more like clay than concrete. It slowly goes from soft to hard… but you have a chance to make changes during the process.
Let me throw in some thoughts:
An architect working with stone, concrete, steel, glass wants to make a long lasting functional and visual impact. Most architecture works outlive their creators and this is a measure of their success and vision for the future.
With few exceptions nobody is using software from 10 years ago or even the previous business cycle. Software is very fluid yet concrete at the same time : with every new release new features are added existing ones are optimized and some old ways are dropped. My point is that once software is concrete it is used to build something even better.
Do not forget that hardware starts as software simulations so hardware is produced by software.
All I know is that every new release when done properly CAN and SHOULD be better than the previous one.