One of my favorite quotes of all time is from Kent Beck:

https://twitter.com/kentbeck/status/250733358307500032?lang=en

I have a few interpretations.

Incrementally Build Features

Break up the work so that the eventual change that accomplishes the goal is easy and low risk. For example, use feature toggles.

Feature toggles come at a cost, and are their own source of technical debt, but make the change easy.

Remove Technical Debt First

Don’t force software to do something it wasn’t meant to do. If the business logic has changed now (or changed long ago), clear technical debt to change the software to better support the needs of today and what’s coming.

This refactoring may be hard, but makes the desired change easy.

Understand The Problem Deeper

By understanding the problem at a deeper level the change can be made easier. I might recognize a pattern that simplifies my mental model and also the technical model. If I write down my architecture plan, I’m forced to fully explain the change. I might recognize an existing system that I can re-use. Other engineers can add their thoughts.

It takes time to think about and write down a plan, but makes the change easier.

Change the Change

The change is not set in stone. It’s an interpretation of a user problem mapped into software, or one of many fixes for a bug. For a given problem there are many changes to resolve that problem. To make the change easier, change what the change is. Work with stakeholders to change their solution to better fit into the software it is being applied to.

Don’t take the requirements of a change as gospel, a different change exists that is easier.