Software Optionality

Have you ever proposed an important refactor only to be told:

Yes, we should definitely do that, but not now…

So, you find yourself in the next cycle. Your focus shifts away from the refactor to now shipping the next feature. Sooner rather than later, that important refactor that you identified is gone.

This is not surprising as new features (should) offer immediate value to users. Therefore, they should be prioritized… right? But what about refactoring? It feels important to us developers, but is there real business value there?

Refactoring is often perceived as an itch that developers want to scratch. I mean fair, given enough time, developers can over-engineer anything for sake of engineering.

And by definition, refactoring does not change the behavior of the system. So managers and product owners may (rightly) wonder if it is worth it? I believe more times than not, the answer is yes!

The main benefit is that (good) refactoring enables the team to capitalize on more opportunities in the future. Kent Beck defines this value proposition as optionality in his new book, Tidy First? , detailing his epiphany:

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. [Chapter 23. Structure and Behavior]

Software optionality represents the value of additional opportunities that arise when you have a running system. Whether you are able to capitalize on these opportunities is a function of many factors: scope, complexity, time, team capacity, and (unique to software) code structure.

It’s sometimes hard to explain the value of code structure to non-technical people. So it is helpful to show other factors that have a negative effect on optionality:

• A key employee quits: processes that used to take days to complete now take months (or worse). There is also the task of replacing this person. Resources that would otherwise be dedicated to product development, are now dedicated to interviewing candidates and sharing the workload of the former colleague.
• Reduction in user feedback: active users provide the team with potential product development options. Without their feedback, it is hard to prioritize what to work on next.

So with bad code structure, instead of making a bold change in a week, it may take months. Or worse, you may spend months on the project only to discover that there were unforeseen consequences to other areas of the application, leading the team to scrap it. Ultimately, bad structure leads to less options, and less options means less value.

In summary, a bad code structure dramatically increases the cost to change. But when software is easy to change and extend, you are in a great position to react to the problems and uncertainty of tomorrow. Instead of being scared of change, you embrace it because volatility means more options and more options means more value to be had.

If you want to learn more about this topic, I do recommend checking out Kent Beck’s book. It will provide you with not only the theory of why this stuff is important, but also give you practical tips on how you can tidy up your codebase.