under construction

Change

Let’s look at change. So far, we’ve considered our problem to be a fixed concern. But what if the problem either changed over time, or as we worked on it?

How does that alter the strategy we use to deal with it? Let’s consider the example of owning a building (maybe a house or a shop), and the functional requirements you have for that building. There are actually only a few basic strategies you can employ for dealing with change:

  1. The Extension. If you need more space for some reason, you can build an extension. But sometimes, extensions ruin the architectural integrity of a building, so you can also…

Lots of extensions

  1. Re-architect. Maybe this involves demolishing some walls, or building a new facade. Re-architecting means taking-away as well as adding new.

  2. Re-locate. If the location of the building is wrong, or the space to build in is insufficent, you’ll end up moving. This might mean breaking ground in a new location, as Apple did par excellence in 2017.

Apple Mothership

In Software

You get the same choices in software, pretty much:

  1. The Extension. Add another software component into your existing architecture, without changing any of the existing stuff. Build feeds into / out of the existing software.
  2. Re-architect. Make changes to the existing software, removing old components and modifying existing ones.
  3. Re-locate. Start again from scratch, with a view towards migrating users from the old system to the new.

You can get a long way with extension on it’s own. The downside of this is that you accrue technical debt because none of the original code ever gets simplified. Let’s build a model of how this plays out in a simple ‘business’ game.

  • Functional Areas (FAs) are things that generate value for the user-base. Each FA generates the same value. It costs £20 to build a new FA, and £2 per-round to maintain an FA.
  • The return on an FA is dependent on the size of the user base, which follows a nice, smooth gaussian curve.
  • You can choose when to build an FA, and it’ll start generating return.
  • However, you’re never allowed to shut down an FA.

– add the simulation here. Parameters: how big should the FA be before investing?

Eventually, - obviously - the creation of new FAs can’t sustain the weight of the existing FAs, and so the business will die.

Now, there are some problems with this.

Firstly, there is no synergy. The existing FAs don’t have an impact on the new ones. It’s always just as hard to create a new FA as before.

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” - The Art Of War, Sun Tzu

Where you don’t know the answer, iteration is really the only tool in the box.

  • risk first diagram for iteration

But this comes with a warning: there are plenty of other problem domains that we’ve looked at where you do know the answer.

  • Don’t reach for iteration as a first resort. Make sure you’re applying this technique to a relevant project. Iteration is about scrambling together a few scratch components that may well get replaced in a later iteration. It’s clearly very different from doing the worst parts first that we saw in Journeys.
  • Iterating takes time. It involves Meeting Reality with your users in a large feedback loop. Because large feedback loops are more costly than smaller ones, make sure you definitely need to do this.

Add Your Star On GitHub to receive an invite to the GitHub Risk-First team.

Rob Moffat
Rob Moffat Author of Risk-First Software Development. Developer. Working in the UK.