One of the very classic analogies in building software is to compare the process to building a house. However in a recent discussion I actually heard someone else, a software developer in fact, compare software design and construction to another profession. I wasn't sure he had a good analogy, and I'm still not, but I did think it was interesting.
So today, my plan is to actually compare software construction to building construction, and talk about the common and uncommon points as well as encourage debate. Over the next few days, I'll pick a few other professions and we can debate those as well. Perhaps we'll come up with a good model, or perhaps not, but I'm sure many of you will view software design differently at the end.
Building a House
I've actually never built a house, or even had one built, so I can't be sure of how accurate my comparisons are, but I have had a building built, I've worked with construction crews for additions and other smaller scale projects, and even swung a hammer or two myself, so I have an idea of how things work. The classic comparison is that building software is like building a house. A plan is needed, foundation is required, inspections should be occurring along the way, then each system in the final construction builds upon others. Some things can be done in parallel, such as electrical wiring and plumbing (sometimes), but often things must be completed before others are started.
As people, we have been building for centuries and modern home construction, while changing constantly in small ways, has been fairly consistent in the last 30-40 years, and that's about the time we've been building software. Since it would seem that the home-building is a fairly well understood process, and we are pretty good at estimating and building structures, perhaps that is how we should tackle software.
There are many writings on this (ntschutta blog, Building bridges and software, and and interesting comparison from Red Mercury among others), but the one I like best is Steve McConnell's Fort Building. It inspired me so much that when I built a loafing shed last summer for my wife's horses, I spent some time planning, estimating, and writing things down. My version turned out to be better than Steve's, about a 3x increase in time from my estimate, partially because I'd just read his story, but also because I tackled a simpler project that didn't need as much visual appeal. Horses don't complain too much about how it looks, and surprisingly, my wife as happy with it.
In other projects, I've run into a few snags that reminded me of software. First the client in building something almost always wants things changed. They don't always get things done, especially when you're billing them lots of money, but they still request changes and the people doing the work have to try and make the changes happen, estimating on the fly. Having worked with some of these people, usually they cut corners, the job isn't done as well, it definitely takes longer, and always costs more. How many of you have gotten a repair estimate and then seen the final bill be higher? I'm not sure that anyone in the building trades is a lot better than software engineers.
You might argue that in small projects they're right on. I'd argue that small software projects, by someone with experience, are often right on as well.
Software has a great advantage over building in that if a mistake is made, the whole thing can be taken down and rebuilt, often quicker, without a loss of materials. In the building world, and I've personally dug this hole myself, a mistake requiring tear down not only loses the time spent, but also a significant material cost. Perhaps this is why inspections, the equivalent of testing code, are required along the way and not optional.
There are many more ways to tackle this, and I could probably write for days on this, but I'm sure many of you have good ideas and points, and I'd like to hear your thoughts on software and structures.
Steve Jones
The Voice of the DBA Podcasts
The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
or now on iTunes!
- Windows Media Podcast - 51.2MB WMV
- iPod Video Podcast - 40.4MB MP4
- MP3 Audio Podcast - 8.2MB
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.