Demonstrates the kind of debt we accumulate if we don’t refactor as we go. This exercise will let the attendees experience the pain of dealing with technical debt, rather than just understanding it intellectually.

Preparation

To start, I give each person a pile of LEGO without any pieces that indicate size (doors, windows, mini-figures, etc). Every person will, however, get a set of sloped roof pieces. Do not give them any flat base plates as that will make the build far too hard.

Note that sometimes I hold the roof pieces back and only hand them out just as they’re about to build the roof part and sometimes I hand them out early. It really depends on the size of the group doing the exercise. I’ve done this with over a hundred people at a time and with a group that large, it’s not feasible to hand things out mid-way.

Note that while each person will get a random set of bricks, it’s critical that everyone has some roof pieces. For this reason, I store them in two separate bags - one for mixed and one for roof pieces only.

Round One

Facilitator will call out requirements that the attendees will then have to build. They should know that the goal is to build a house but they won’t know the specific requirements up front and will only discover them as we go.

One new requirement will be given every 30 seconds. At the beginning, 30 seconds may seem too long but they’ll be rushing to keep up once the exercise gets going.

⮕ Constraint: Once two pieces have been connected, they may not be separated again.

This simulates not refactoring and the code becoming harder to work with over time. You will likely have to remind them of this constraint several times through the exercise.

Requirements

• “House must have two connecting walls”
  The walls must actually be connected and not just standing beside each other.
• “House must have a window on one wall”
  At this point, they usually need a reminder to not separate bricks.
• “House must be fully enclosed. Add more walls”
• “House must have a sloped roof”
  Point out that they all have sloped roof pieces and encourage them to make the slope prominent and visible. “Show it off.”
• “House must have a chimney”
  At this point I’m usually saying that this house is being built for the frozen north and therefore needs heating. I’m usually trying to stress the business need and not just the fact that we’re building something.
• “House must have a ground floor door”
  With luck, they won’t have enough room for a door and will have to add to the bottom instead of the top
• “House must have a window on a second wall”
  If this means building up again then ensure they still have a ground floor door
• “House must now have a flat roof. Marketing tells us that sloped roofs just aren’t selling. If buyers even see a slope, they won’t buy so cover it up”
  This is the point where all their previous decisions come back to haunt them. Remind them again that they can’t separate pieces.

The expectation is that each step they take will make the next step more difficult and so it will take more time to implement than it should. I usually give 60 seconds for the last one, instead of 30, because it’s significantly harder than the others.

In order to satisfy the flat roof requirement, most people will have started down the path of a stovepipe architecture¹. This is a good time to discuss that.

Debrief

• “What did you notice? Any surprises?”
• “Were you consistently fast at implementing new features or did it get harder as you progressed?”

Round Two

Do a second build. If there are enough LEGO® bricks then leave the first build assembled so that we can compare them.

What’s different with this build is that everyone is allowed to separate the bricks as needed. This simulates refactoring to keep the code clean.

Debrief

• “What did you notice about the second build?”
• “Which version was easier to build on?”
• “If you had to keep building on one of the two builds, which one would you want it to be?”
  Every once and a while, you’ll get someone who insists that they prefer the first one. These people are often the heros who get recognition from being able to fix the problems that stop everyone else, and are therefore incentivized to make things worse than they should be. For everyone else, the second (refactored) version is much better.
• We commonly hear “we don’t have time to refactor” so ask “did the act of refactoring slow you down?”
  The answer, of course, is that having done the refactoring make us go much faster even when we take the time to refactor into account. This applies to code as well.