Summa

The analogy of “constructing software” as “building houses” is useful, but also flawed. 

Although both Software Construction and Housing Construction are both engineering practices, we have been way more successful at estimating the cost and effort of building houses than software.

There are strong reasons why such a task is difficult, and recognizing these challenges is the first step at improving software estimates.

The Vocabulary barrier

Because most of us have lived in a house our entire life (I’m not counting those guys from the Geico commercials), we developed a well defined, understandable, and almost universal vocabulary to describe and discuss things related to the place we call home. When asked what our house looks like, we can do it easily. When planning a new house, we can most certainly talk about what we want and be confident that the Architect and Engineers will understand what we’re talking about and vice versa. We might not understand the plumbing and electrical details, but we know where we want the electrical outlets, the size of the rooms, how many garage doors, and how we want the house to work -basically, which “functionalities” we’re looking for.

When talking about software, we’re not that effective. There are so many new terms, both from the business and technical side, that we often need to rely on real world analogies to explain them. There are also technical, obscure, esoteric terms that transform even simple statements into incomprehensible discussions. It happens not only between business and technical people, but even between peers. We’re not used to describing software requirements and because of all the abstractions of software, at estimation time the communication is often affected by noise, misunderstanding, and a lack of sight, increasing the uncertainty about what really needs to be built.

Physics

The real word has very strong and stable rules, like gravity, and these rules impose a lot of constraints when building a house. We know that we have to finish the basement prior to building the second floor. We can’t increase the number of floors after the foundation is complete. It may be very, very expensive to change the location of the bathroom after the plumbing is in place.

In a software project, we live in a world with fewer rules, almost like the Matrix. Technically speaking (and I’m not saying this is a good idea) we can build all the layers of the application at the same time. It can be designed to work with different databases, run on different servers, or support different languages. It can be accessible through a browser, a cell phone, or other wireless devices. The options are almost endless.

It is exactly this freedom and flexibility that has driven the huge advancement in software in the last 40 years, but, at the same time, it is also the cause of countless failed software projects. It is crucial to be realistic with requirements, and to make them abide by some ground rules even though they’re not forced to by the physical laws of the universe.

Procedures

The combination of physics and thousands of years of construction has resulted in a reliable set of procedures for how to build a house. Although there will always be new materials and improved techniques, the core concepts are the same. The process to paint a house has changed little in hundreds of years.

We are still in the earlier phases of software engineering. A lot of “gut feeling” is still used when estimating software, and the reality is that gut feeling has not proven very effective. 

Materials and Standards

There are a limited number of materials that can be practically used when building a house. Technically speaking, there are probably hundreds of options to build a wall (plywood, concrete, steel, sand, glass), but at Home Depot the options are very limited. The type of paint, the model of windows and doors are many but limited, and are often visually available at the store or through a catalog. 
When buying a sink for a house the chances are high that it will easily be compatible with the plumbing in place. The appliances will “speak” the same voltage and the light bulbs will be compatible.
A plan to build a house where everything is compliant and materials are popular is more than possible and will have reduced the uncertainty to very small levels, increasing the accuracy of estimates.

The software industry does have some standards in place, but they are on the lowest level of the layers, network protocols and file system for example. Integration between servers and products are yet on the “wiring” level and XML and Web Services still have a long path to go before they reach the same level of compatibility found in construction, if that’s possible at all.

The variety of options and ways to connect to a database and architect the software adds complexity and increases the learning curve of everyone involved in the software construction effort.
I’m not saying that having all of these options is bad, but it definitely adds uncertainty, and therefore complexity, to the estimation phase.

Roles

Every time I stop by a construction site I see a lot of hats, some actively working, some waiting for their time to act. But the best part is that I have never seen somebody wearing two hats at the same time. The roles are well defined and the workers specialized in very specific areas. 

In large software projects there are some roles defined, but not even close to the same level of specialization we find in construction. Often members of the team needs to wear more than 1 hat and the consequence is that sometimes they will be executing tasks they’re not specialists of, which increases the uncertainty about the estimates they provide.
A good example of this “many hats” phenomenon was the “Webmaster”, a role used to describe that guy doing the web page design, creating animated images, writing HTML and Perl code, configuring the database, and managing the network and mail servers. Fortunately the webmaster is a term now seldom used since all these activities are now allocated to different roles like the Web Designer, DBA, programmer, and system administrator.
We’re definitely moving towards specialization but there is still a long way to go.

I’m not proposing that we stop using the “let’s build it like a house” analogy but we must be aware of the limitations of this analogy. Once we know the limitations we’ll be better positioned to discuss the gaps and provide recommendations on how to address them.

If you excuse me I gotta go fix a leak in our bathtub.