Software Lessons from Property Brothers

Yes, I know the “software is like construction” metaphor has been overplayed, but hear me out here. One of my guilty pleasures is a home improvement show on HGTV, Property Brothers. The show covers a home buyer who wants the house of their dreams, and renovates an older, more affordable home to do so. The gimmick is it’s one twin that helps the home buyer select a house to purchase, and the other to renovate it.

Scoping Phase

The show starts off with Drew (the Realtor) working with the home buyers for their “must-haves” in their ideal home, as well as their max all-in budget. Typically this list is something like:

  • Open floor plan
  • Hardwood floors/granite countertops
  • Big chef-style kitchen
  • Spacious master bedroom/walk-in closet/master bath
  • Big yard
  • Man cave (but never a woman cave because reasons)
  • X many extra bedrooms and Y bathrooms
  • Location close to work/family/city

Drew then takes them to a house that meets every single one of their criteria. The homeowners fall in love with this house, seeing a move-in ready home that has everything they want. Then Drew asks them, “how much do you think this house is on the market for”.

At this point I wonder if the homeowners are universally idiots, having done zero research or it’s just the Magic Of Television. The homeowners will guess a price maybe 10-20% more than their max budget. Drew then does the reveal of a price at a minimum of 50% over budget, sometimes 100-200% over. They’re looking for a dream house of $500K but in reality it would cost $750K and up.

This serves not to shock the homeowners, but to reset expectations. If the homeowners want the perfect house in the perfect location, they’ll have to pay a lot for it.

We have to do this quite a bit in software development. Reset expectations of what someone thinks they can get for a certain amount of dollars/time/people to what is actually attainable. And like home renovations, throwing more people at the problem won’t necessarily speed things up, there is a physical constraint in the space you’re working in as well as dependencies between steps (can’t paint the walls until you actually build the walls). You can’t easily parallelize work, and when you do, there’s a lot of management/coordination overhead to doing so.

Design Phase

Once the homeowner picks a “fixer upper”, Jonathan, the other twin and licensed contractor, takes over and directs the renovation of the house. He goes over a proposed design (that’s not exact on the little things but on the bigger things like where bathrooms should be) and budget. He works in a contingency budget, typically 10-20% of the overall budget, that he saves for “nice to haves”.

The proposed design is interesting in that it parallels a lot of the architectural and design decisions we make up front in software. We work out the hard problems that are hard to change, architecture, and provide a vision of the design typically through a couple of wire framed interactions along with a style guide. Nothing is set in stone, and Jonathan’s design shows colors, furniture and the like but none of the cosmetics are set in stone. These are the items that wouldn’t really affect the overall budget but get an idea of what the final design would look like.

Implementation Phase

Once the homeowner picks a house, they put in an offer and through the Magic Of Television have the offer accepted. Although not always, sometimes the homeowners decide they know how to negotiate better than a professional, tell Drew to put in an insultingly low offer and it gets rejected without a counter and the homeowners are disappointed (to my chagrin). But a house is eventually purchased, and the project moves to demolition and renovation.

Inevitably curve balls are thrown in. A wall they wanted to open up turns out to be load bearing, and the owners have to decide to keep the wall, or put in a supporting beam at the cost of trading off some other element. It’s always tradeoffs, and it’s always in the homeowner’s court to decide what they would like to trade off. The contractor tries to hold them to their budget, because typically no one is happy if they spent more than they planned (even if in the moment it seems like a good idea).

Individual elements can be decided as they go, such as what kind of cabinets, flooring, furniture and the like, but the big decisions on how the rooms and plumbing should be laid out are decided up front. It’s just too costly to change these later. We see this in our projects, too. You could go the route of building small prototypes/services/whatever and expect to throw them away, but these still cost time and money to build. It’s worth instead taking some time up front to evaluate priorities and make some decisions on the big choices, but deferring the smaller decisions until you’re really forced to – the last responsible moment.

The metaphor isn’t perfect, but it does at least serve as a common reference/talking point when trying to explain how software design and development works, in a way that brings the client along with the process, keeps them involved but shepherds them along a well-worn path to success.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile, Architecture. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • but the big decisions on how the rooms and plumbing should be laid out
    are decided up front. It’s just too costly to change these later

    And yet i’d say it’s more of a standard than an exception to the rule, in our industry to add a microwave to the kitchen requires bulldozing the house, applying giant sticks of TNT to the foundation, and starting over from a hole in the ground with some leftover sticks. I mean there is literally a “no plans” movement

    • George McCormick

      You hit the nail on the head – “No plans”…

      • Stephen Byrne

        Don’t hit the nail! It’s stuck into the dynamite buried behind the wall :)

  • Arturo Hernandez

    Yeah.. sorry, but I don’t like this metaphor. In particular because it leaves reuse out. With every bedroom you add to a house you get a lot of fixed costs. Which sounds to me more like cut and paste.

    The metaphor I like best is writing up a contract. Although is not as sexy as building a modern house. You probably don’t want to cut and paste in a contract either, because you end up with a huge unreadable and unmaintainable mess.

    • jbogard

      There’s *tons* of reuse! My hammer, my saw, my screwdriver! Plumbing, HVAC, are shared infrastructure. Concepts are reused – doors, windows, walls etc. Blueprints are reused, then the details customizable. Everywhere I look in construction there’s reuse, it’s how they’ve made the business model so efficient.

      • Arturo Hernandez

        You are reusing your tools, but not the product of your labor. Plumbing and HVAC do have more of a reuse feel to it. But that is smaller and a less obvious portion of the house. Every time you install a door you have to get a new door, put trim up, square up the frame ect..

        • jbogard

          Yes, every time I create a new screen in an app I create a new controller action, new model, new data entries. The re-use is in the infrastructure, rarely in the business logic. My reuse is using a hyperlink from two different screens to one screen.

          Every metaphor breaks down eventually, though.

      • Arturo Hernandez

        If you want to. It is possible to map the concepts behind construction building so it feels like building software. For people like us who make software, it may be easier to do. But honestly, I just don’t see it as a simple and clear metaphor. After I used it, I often felt like non-programmers understood what I was trying to say. But it took way too long to explain.

        • jbogard

          Beyond metaphor, I look to it as a way to learn lessons from industries that have been around waaaaay longer than software. I don’t necessarily explain the metaphor with every client, but I try to lean on other industries on their lessons learned. Software isn’t the unique and delicate snowflake that has been made out to be.

    • jbogard

      I actually do really like the contract metaphor for OO. I use that or something like a government form (tax form etc). Also doubles well for messaging – there’s a contract, it has data, implies a protocol of how the work will get done etc.

    • I know this is an old post but I assure you that your home is by far one of the most reusable things you’ve been exposed to. That bedroom can be for sleeping, eating, storage, working, exercise, entertainment, and so on.

      Very few people ever build a software system that has reuse that even scratches the surface of reuse that exists in a house. Most people who are responsible for designing software have no idea how to actually design software to be reusable at all.

      Look at the power outlets that are in your room. That’s a textbook example of reuse. How many software systems are built that are easy to plug into as a lamp is to a wall outlet? A well designed software system it’s literally that easy because you have the contract defined of “wall outlet” and are able to just plug anything into it. The extreme majority of software systems have very low cohesion, no consistency, and no reuse. If you don’t use your software system to build the software system, your system has no reuse.

      • jbogard

        A plug to me is akin to Ethernet or HTTP, no?

        • I agree on ethernet. On HTTP, not so much. Since with HTTP I’d say there’s 8 billion different receptacles and good luck having all the adapters to connect any arbitrary set together. Both America and Europe have electricity but have fun plugging in an American plug in Europe without burning something down, that’s pretty analogous to how HTTP gets used today (excluding basic content servers that generally behave very consistently)