When software architecture isn't like building architecture
We've all been through the talk about how building software is like building buildings. That somehow there's a correlation between creating a software model of reality and a physical model. I've even given presentations and taught course material that made comparisons between how we build buildings from the ground up with a plan and that we should do the same thing with software.
I'm sure we've all heard the flip-side of the same discussion which says that software architecture is somehow very different from building architecture because software is mutable. That is, if we get parts of it wrong today we can go back and fix it.
For the most part both of those arguments seem to hold. We want to build software with a plan and on a stable base. We build buildings that way and things turn out well. Right?
I noticed a difference last night when I received an invoice for "additions" which were made to my house. For those of you who don't know, I'm in the middle of a huge remodel project; this invoice was, I had assumed, my monthly "catch-up" payment against the original bid.
So, what's different between the two worlds. Well, in both software and buildings estimates can be incorrect. We don't always have all of the information we need so we make guesses. That's why we call the estimation process an estimate. It's not an exact science. At least it's not in the software world.
We've been building homes for many, many years now and we know a priori what's going to go into their construction. In fact, most building estimates are extremely close, which is why I was making monthly payments against the estimated cost and schedule. Well, I realized last night that it's entirely possible to have an immediate 20% cost overrun building a house (or remodeling one as it were). Why did this happen? Well, turns out that the architect hadn't done all the planning that typically goes into a house remodel plan -- he forgot three windows and ALL OF THE LIGHTS.
What's this got to do with software? Well, in software we learn things as we build the product. We do this because it's not possible to know everything about the product before we start building it. Cost overruns happen, and when there's doubt about the cost to build a feature developers even over-estimate to cover their asses and their customer's asses. Building architects never over-estimate. Ever. Not once. They always figure out everything they need to put into the project and everything "new" after that is a change order. They can get very good estimates this way and everybody comes out happy in the end. Unless the architect forgets ALL OF THE LIGHTS.
