This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Your Software is not a House
I’ve said it myself before – this software needs to be designed properly; You know, foundation of a house, and such. Once the design is solid, oh just trust me, we will create some software real fast. And then we went off to ponder and pontificate, and create documents showing how elegant this solution would be. We used and diagrammed all of the proper patterns, creating interfaces and abstractions along the way.
We wrote code; tons of code. We deviated as we learned more of the system, as time became tighter, and so on. Once the project was released, ‘Someone should really update that design document’…and no one does.
Would you want the real version of the house based on the software you build? Would you want your contractor to agree to a set of prints up front, but once you move in realize that the only way to turn on the lights was to flush the toilet? How about that study you wanted? Would you be happy if your carpenter decided that you, ‘the user’, wouldn’t need a study? Would you feel better if afterwards, the architect came back and updated your blueprints?
4,192,876,492 – that is my estimate of the number of unneeded interfaces in code out in the wild right now. Would you want that many light switches in your house, you know, in case you wanted to switch something else on besides the ceiling light?
Houses can have blueprints because they are based upon static principles with high commit costs. A foundation is made of concrete. You can change it but it will cost substantially and can create structural risk. Software is malleable and code is not concrete. We should be exploiting that benefit instead of trying to move towards a less flexible model.
Lets take this a step further. Houses are built upon civil engineering principles – stress loads of materials, heat dispersion, pressurized values of systems. For example, the beams supporting your walls are probably slightly over 14 inches apart. That is not because that was a good number to go with. That is because we know, through testing, that the stress load we can expect a wall 2 by 4 to support is actually 24 inches on center but because of the varying in woods (drying, species), most carpenters build at 16 inches on center.
What would be similar in concept to this? Programming languages, platforms, maybe containers or software development frameworks. We know how languages function in certain applications and situations; what platforms work best for certain targets; what containers will provide for us. Even these can be changed – swapping containers shouldn’t be painful. These items are addressable upfront.
Finally, have you ever heard of a civil engineer say ‘concrete isn’t good enough for this common residential house, I am going to invent something new.’? You don’t, it would be ridiculous, overly costly, and people could die. But in software, too often we design and say something similarly absurd. ‘We need a custom web server, Apache wouldn’t scale for our special problem’. That statement is as ridiculous as trying to make your own concrete.
Read more by Joel Tosi @ http://communalosmosis.com/