Chapter 23. Structure and Behavior

In theory, this business could run forever, producing $10 for every dollar we put in. We know this is an oversimplification. Bit rot is real. Something is always changing. Staying in place in the river requires constant paddling. But for purposes of the distinction I’m drawing, this is good enough for the moment.

You know what’s better than a machine that spits out $10 for every $1 you put in? A machine that spits out $100 for every $10 you put in. Or $20 for every $1. How are we going to get to that better machine?

In a word, optionality. The mere presence of a system behaving a certain way changes the desire for how the system should behave (Heisenberg’s uncertainty principle). However much you’d pay for the $10/$1 machine, you’d pay more for one that could turn into either a $100/$10 machine or a $20/$1 machine—even if you didn’t know which it would turn into.

This is the secret it took me decades to absorb. I didn’t have to change the behavior of my system to make it more valuable. As soon as I added to the options of what it could do next, I had already made money. (I went down the rabbit hole of options pricing formulas to really cement this understanding, but I trust you to figure out how to convince yourself.)

One of the coolest thing about options is that the more volatile the environment is, the more valuable options become. This was part of my motivation to subtitle my book Extreme Programming Explained “Embrace Change.” As a young engineer, I was terrified when a seemingly settled situation turned chaotic. As I learned to enhance optionality, I saw chaos as an opportunity.

What interferes with options? Here are some scenarios that reduce the options value embedded in your software:

• A key employee quits. Changes that would have taken days now take months.

• You distance yourself from your customers. If you get a provocative suggestion a month instead of one every day, you have fewer options.

• The cost of changes skyrockets. Instead of being able to exercise an option a day, you can only exercise an option a month. Fewer options, less value.

Nothing in the scope of this book directly addresses the first two of these options killers, but we can react to the third. We can keep the kitchen clean as we cook.

The structure of the system doesn’t matter to its behavior. One big function, a whole bunch of itty bitties, same paycheck comes out. The structure creates options. The structure could make it easy to add new countries to our paycheck calculation, or it could make it hard.

Here’s the problem: structure is not legible in the same way behavior is legible. There’s a reason product roadmaps are lists of features (behavior changes). It’s easy to see when the behavior changes—a button appears that wasn’t there before.

Even though we know that we have to invest in structure to maintain and expand optionality, we can’t really tell if we have. The code is easier to change? Really? We can’t really tell if we’ve done enough. If we invested more in the structure, the code would be even easier to change? Really? We can’t really tell if we’ve made the right investments in structure. The structure changes we made were the best way to make the code easier to change? Really?