Yesterday I emplored you to make changes that you can make with absolute confidence.

What if you can’t make any change with confidence?

Kent Beck addressed a similar issue back in 2012 with his now-famous Tweet:

For each desired change, make the change easy (warning: this may be hard), then make the easy change.

If a change can’t be made with confidence… first work on gaining confidence, then make the change.

What would give you the confidence that fixing that bug won’t cause other bugs? Or that your new feature won’t upset users? Or that your refactor is actually a refactor?

Sometimes the answer is that your projecte needs more or better tests. In fact, that’s often the answer. But not always.

If your goal is not to upset users, automated testing probably won’t help. You might need to talk to your users! 😱

Honestly, what surprises me is that this approach isn’t more common in the world of software development. It seems to be normal in many other industries.

A couple of years ago, when we did some remodelling work in the attic, we put a brace in place before removing one of the support beams. We made the change safe first.

If my attic had been like many software projects, we would have just removed the support beam, watched the roof sag, finished the work, painted over the cracked walls, then hand it off to QA, and wait for them to report the problem before we’d go back and do the (much more expensive) repair work.