Why Software Projects Aren't Like Building Houses

It never fails. On every project, someone eventually uses the house analogy for building software. On the surface, a house does have some similar concepts that can be attributed to software projects such as:

·       A Foundation (Platform)

·       A Front Yard (User Interface)

·       A Back Yard (Backend Processing)

·       Rooms/Components (Features)

This is however where the comparison starts to break down. What people seem to take for granted is that mankind has been building living structures for thousands of years. The other thing left unspoken in the house analogy is a house has a proven certified architecture before it's even built. In a typical scenario, a builder isn't designing the architecture of the house on the fly. The average home builder is already working with designs that have already been certified by an architecture firm. If a custom home is being built then the process of building the house takes significantly longer. Even with a proven design city permits typically need to be acquired adding to the length of time before the construction crews can even start.

Another place the house analogy breaks down is homeowners don't typically decide they want to change the architecture as the house is being built. If we applied an agile approach to home construction then walls would be moving while workers were trying to put up sheetrock, rooms might disappear or change dimensions, a one car garage might turn into a two car garage and so on.

When is the last time you saw 10,000 people living in the same house? Most houses are called single-family homes because a small number of people live in the entire house. When we deploy enterprise systems we're looking at thousands of users each with their own opinion of what they want and need. I can only imagine the line to use the bathrooms in that house. We actually may need to build a scheduling app to go with the house.

How many houses have you lived in that needed a training manual or web seminar? Oh and there's also the logistics of delivering that training to the thousands of people that live in the same house across different time zones, languages and geographies. I guess there are a lot of pre-existing design patterns that we learned from living in houses our whole life we take for granted.

In my opinion, while the housing paradigm can certainly be helpful in a certain understandable context it largely over-simplifies the work that happens in a successful software project. Software teams have to not only come up with a working architecture that will work with the specific technical environment but also conform to corporate, industry and government policies. They must do this as they are still discovering new requirements and refactoring new and undiscovered business rules. They have to integrate with external systems that most likely weren't even designed with integration in mind. All this has to happen under tough timelines, budgets and resource constraints.

So, next time someone compares greenfield software development make sure they compare it to building a new house from scratch - on Mars perhaps.