I was watching Holmes on Homes today and got to thinking about parallels (or lack of them) between renovating and building a home vs developing a software application. Some of what I was thinking ties in with the "software development as craftsmanship" discussion that pops up every now and then, but mainly this is just a brain dump.
First off, let's set this up. What I'm thinking is that a "software application" maps directly to a "home renovation project" or just actually building a new home. Here are some of the obvious parallels:
- In a home building project you have a general contractor who oversees the entire operation, hiring other contractors or bringing in employees as needed. Software projects will generally have some sort of equivalent "lead/architect" role.
- Both projects would have clients that most likely have no idea what's going on. They see the end result and have no way of knowing whether that result will last 2 months or 20 years. Generally, as long as the finished product looks pretty and seems to do what's required the developers/renovators will get paid.
- Size matters in both professions. Anybody can hack their way through installing new countertops or building a simple CRUD web app, but the bigger and more complex the problem gets, the more professionalism and care is required. I'll take a calculated leap and say that many of the problem projects in both professions happen because somebody who can "install a new faucet" gets it in their heads that they can also "renovate the entire basement" using the same amount of knowledge and preparation.
I'm sure there's a few more parallels, but you get the idea. Now let's focus on some differences...
- A general contractor doing a home renovation will bring in "specialists" to work on individual pieces of the project, whereas many software projects are made up of "generalists". As programmers, we are often tasked with developing business logic, writing html, security, usability, system administration, deployment, testing, etc. Just look at the range of what's required in the average job posting for a software developer. This is obviously not true in all cases, but in general this is what I think is happening out there.
- The home building industry has these crazy things called "inspections" that are supposed to ensure the builders don't pull some crazy shit that could endanger the client. Imagine code inspections (by an honest inspector we hope) and how they could protect a client... An inspector could obviously not be expected to know if the application is running a calculation correctly, but that is the one thing that a client can confirm. An inspector could, however, check for signs of incompetence such as SQL injection vulnerabilities, obvious spaghetti code, code duplication, lack of tests, poorly designed databases, mangled HTML, obvious usability disasters and so on. Once notified of the issues, the client would be able to take action as they see fit.
My thinking is that, at least in my own experience, the best project I've worked on (in terms of happiness of the client and its likelihood of being maintainable for years to come) was the project that was most similar to a successful home reno project. We had a UI specialist, a bunch of developers focused mainly on the business logic, and testers. Other "specialists" were brought in as needed for database tuning and system admin type work. An "inspector" even came to the project at one stage. This inspector was Eric Evans, who showed up and observed the project for a week and delivered a report on what was good and what could be improved. This visit seemed to be largely positive (I showed up a few months after he came so I can't know for sure) in the sense that it gave the development team some reassurance and some focus on what could be improved. I'm not sure what the clients got out of it.
I'm wondering if a working on a new project with the goal of running it consciously more like a home reno project could improve things. For example:
- Think of hiring for "concerns" instead of technologies (ie; security & usability instead of Java & Struts).
- Have a defined "general contractor" role that is in place to hire and fit all the pieces together.
- Allow the specialists to come and go. There's no need to keep everyone around all the time. Call them in when there is a need.
Based on my own limited experience I think doing software development as a home renovation could really work, especially when it comes to focusing on roles and quality. Should any project be open to an SQL injection attack ever? Hell no, there's just no excuse for that kind of incompetence. But so many are... Inspections and specialists might be one way to mitigate this.
In closing, I'd like to hear other people's thoughts on this. If it's already been said before (better hopefully), I'd like to read more about it.
10-31-2009 6:18 PM