skip to Main Content
Stop Saying Software Development Is Like Building A House

Software Development is Not like Building a House

For several decades, I have been involved in software; building software products for large companies, growing a startup, and even running a boutique consultancy for 10 years. I now do independent product development helping client turn ideas into software products.

Many times in my career I have heard software development described to a client the same way you would create a house. This metaphor made sense on the surface. A house is something that the clients could relate to. There’s a design phase where they talk about what they want, then there’s the building phase where the design is implemented.  

Does this metaphor sound familiar? It should; I have heard it from clients and other developers. But it is dangerous to use something so concrete to describe a medium as fluid as software. I now avoid using home construction as a metaphor for software development. Here’s why:

Scope can change dramatically after the contract is signed

As the client sees the product come together they reach realizations and will want to change the design. If we were building a house, it’s like the client casually mentioning that they want to add another bathroom on the second floor—right after you agreed on a price.

Unlike a house, software is made to be changed. Whereas a house is a largely static product, software needs the ability to adapt to changing demands, many of which present themselves during development. The catch is that clients cannot easily see all the work that goes into those changes, so they struggle to understand the complexity introduced with a new request.

Software processes can be complex

Building a house isn’t simple, but most people understand that first comes a design, and then you build it—that’s the process.

By contrast, software development can employ a number of flexible processes that many people aren’t familiar with. Processes like weekly stand-ups, sprints, backlogs, retrospectives give development teams the ability to quickly adjust to the changing needs to a project.

I find myself educating clients as fast as humanly possible. Without taking the time to explain how we change the software, and in-turn budget, the project would simply seize up.

The good news is that agile methodologies and the like are slowly permeating other industries and schools, but until these concepts gain wider acceptance, essential client education takes time and patience.

Cash flow will strain the client relationship

If you apply for a construction loan, the bank wants to be sure of a few things before they’ll agree: the likelihood that you’ll pay them back, how legit the construction firm is, and if the costs of the project are reasonable. The bank won’t take the risk if any of these criteria don’t match what’s expected.

When all of these things do align, the process works well; the bank doles out money to the builder as costs build up. The builder knows that there is money, the client knows they will be spending it, and the bank controls this in the middle.

Software is nothing like that at all. To start, there’s no guarantee the client has any money, so it’s usually on the risk of the builder to pay their own people until the costs are covered. That can easily end up being 60 to 120 days depending on the terms of the agreement. It’s unfortunate, but right after a contract is agreed on, it’s a little like the developer—using their own funds— just extended credit to the client, all based on a handshake.

Sure, this can be solved by having the client pay up front. But there are always other firms willing to jump in to get the business, and the pressure is always there to just make a sale. As a development firm, it takes a lot of discipline to properly deal with the financing before the work gets started.

Estimates might be the biggest problem

In the middle of every project is the budget. For the construction industry, they can get three bids from subcontractors and calculate material costs. My brother in law does this for hospitals in Missouri. As complex as this is it is fairly precise.

In contrast, for the software developer, this process is much more based on intuition and experience. Construction processes can base time and material costs on square footage, linear feet, volume, and other measurable metrics. Software lacks this hands on relationship. Estimates simply have to be summation of estimated risks. We have a couple techniques for this, but the process is wrought with variables. There are many places where this can be miscalculated. For example, the client might not have told you of everything they wanted, the developers might have misunderstood the requirements, or the technology landscape can change while you are in the middle of creating the product.

These are the obvious things. Then add scope creep, legacy code, and code debt, and things can balloon quickly. If this estimate is wrong, there’s immediately a problem. The longer that problem isn’t addressed, the bigger it’s going to be.

As developers, we have ways to mitigate this, like doing development spikes to test technology and adding integrated tests to see if legacy code is usable. But in the end, a number has to be agreed and you’ve got to do it quickly to start the project.

A better metaphor

Let me propose farming as a better metaphor for software development.

It takes time to grow a crop, and there’s always the risk that it will fail due to weather, insects, and countless other external variables. It also takes time to grow a software product. Slowing things down increases the chances of success.

In my experience, it takes at least a month to just think through an idea. It takes at least another month to build a prototype that you can test internally, and it can easily take one to three months to produce a product that’s ready for release.

It is totally fair to say that a software product takes three to six months to grow, and at that point you basically have some young plants. It takes even more time to get it scaled up for a commercial release.

Sure there are magic fertilizers, ninja farmers, and amazing machines you can rent. But people need time to think, experience, and learn because that’s when ideas grow.

Don’t construct a house out of software. Take the time to grow a product.


  • Matt Paulin

    Matt Paulin is an engineer and entrepreneur that works with teams to turn ideas into products. As a developer he has been involved in many startups around Seattle the last several years; OfferUp, Rover, Cheezburger, and his own crowdsourcing startup. Matt wants to see more great ideas turned into products. You can follow Matt on Twitter here.

    View all posts

This Post Has 4 Comments

  1. People who think that the construction industry can reliably deliver on time, to budget and on spec have never had anything built for them!

    It is true that as construction tends towards manufacturing, say in erecting McMansion #127 of 200 near identical houses on a new estate then then it can be expected that everything goes pretty much to plan. But that’s true in software development too—adding another web page/database/webpage circuit much like the other 100 in a web app much like the last 20 that we built can also be expected to go pretty much to plan. In both industries it’s when we build new kinds of solution using novel techniques that things go awry. Read up on the utter chaos of the new Wembley Stadium for one particularly bad example.

    In Europe, and the UK in particular, the civil engineers and allied trades grew weary of spending so much time in court with clients, employers and contractors suing and counter suing each other to see who was going to end up paying for the changes, mistakes, surprises and general muddle of large, complex construction projects that they invented a whole new kind of contractual basis on which to run such endeavours: the New Engineering Contract, now on its third iteration. Unfortunately, a lot of the NEC3 materials are proprietary (and expensive), but the principles behind it are public: cooperation, collaboration, transparency, sharing risk and reward, making issues visible early and all working together to resolve them without blame, maintaining the highest focus on safety and quality. Sound familiar?

  2. Isn’t it suitable to name any industry by what it does for the clients? Sure it may seem relatable to other industries in a number of ways but software development companies must be known for what they do as the part of their service.

  3. As per the current demand constriction industries also using the software and i am agree with the point as you have shared this wonderful information with us. Keep doing great work.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top
Skip to content