Beware of Shotgun Surgery

Have you ever had to make one change after another merely to fix a bug or add a minor new feature?

If so, you’re familiar with Shotgun Surgery.

As in, “I’ve just performed Shotgun Surgery on the billing software. Hopefully everything will be fine.“. Hmm, I don’t rate your chances.

In medicine, surgeons prefer to affect as little healthy tissue as possible and opt for keyhole surgery to minimise soft-tissue damage and subsequent healing. This minimalistic approach makes sense; the body has less healing to do, and recovery will be faster.  

Imagine the opposite of keyhole surgery—Shotgun Surgery. The only medical equipment the surgeon has is a shotgun. Even if the operation is an apparent success, the patient will be reeling from multiple brutal wounds and will likely succumb. There is a good reason shotguns aren’t standard equipment in most operating theatres.

Shotgun Surgery

Unlike in medicine, in programming, especially in legacy code, shotgun surgery is commonplace. And how could it not be; when the behaviour we want to change is distributed throughout such a codebase? The nature of the code forces us to make modifications in many places at once.

Shotgun Surgery. Changing many files in one go to achieve the desired behaviour change in the system. The chance of introducing bugs is high.

The need for Shotgun Surgery is a symptom of Rigidity. 

As programmers, we want to change software behaviour by making as few code modifications as possible. The term ‘Software’ indicates material meant to be soft, malleable and easy to change. 

Rigid Software

Often the opposite is true—the code seems ‘hard’, resisting change. Such rigid programs require multiple edits in different files and seemingly unrelated parts before we have successfully produced the desired behaviour. 

Altering code in many places dramatically increases the risk of introducing undesirable behaviour—i.e. bugs. 

We can try and guard against bugs by ‘being careful’ and extensively running and testing the behaviour of the code post-Shotgun Surgery. However, we may find it nearly impossible to be reasonably confident about not introducing at least some bugs. When our modifications are widespread, we may unwittingly alter the flow of 1,000s of execution paths, with only a tiny proportion thoroughly tested by us. And so we must cross our fingers and pray that our efforts suitably placate the often-volatile software gods.

What can we do to ensure we cause no bugs when Software Surgery is necessary?

Cover & Modify

The only way I know of guaranteeing we don’t introduce bugs while performing shotgun surgery is to cover the code we intend to edit in automated tests, preferably unit tests. Why unit tests? Because they run quickly and predictably every time. The last thing we need is tests that cannot reliably predict broken behaviour—as is if the rigid legacy code wasn’t enough of a problem!

The software is rigid, and we cannot get away from making many changes in the code. However, we can cover the affected areas in unit tests (green) before making the modifications (red). Our early warning system is in place—now breaking tests will indicate broken system behaviour.

Once the areas of change are covered in unit tests, we can make our shotgun surgery knowing that tests will break if an edit introduces unintended program behaviour. 

Sounds great, right? But won’t introducing such unit test coverage in legacy code take considerable time and effort? Much longer, in fact, than just undertaking the shotgun surgery without tests?

Sure, it will take longer, possibly much longer, but you’ll have taken the first step towards full test coverage of your legacy codebase. Even though it’s a long and sometimes hard road, introducing additional tests will become easier with time, and you’ll be able to refactor and clean the code with increasing confidence. Finally, Shotgun Surgery will become rare in your test-covered and renewed software.

Alternatively, you can sheepishly explain to a livid CTO why tens of thousands of customers were billed the wrong amount this month.