Eating Legacy with 3P

When you write tests or refactor at the end of a story, or worse in a separate story, who gets the benefits? And when?

It's the next person who touches the code ... sometime in the future ... if we're lucky. Given that the tests remain relevant. And given that the refactoring actually helps with the new functionality, that we don't know yet ... 🤔

That means our efforts in refactoring and tests are primarily for other people, sometime in the future and of uncertain value to them. Is it surprising if we don't do much of it and let the code rot?

*An alternative, that maximises the ROI of the tests and the refactoring, would be the Protect-Prepare-Produce* method 🧐.

# Protect
Write quick and dirty(!) tests to protect refactoring in next step. Beware this can hurt some sensitive viewers.

# Prepare
Refactor in depth to make the new functionality easier. Also make the code testable and improve the tests written in the previous step.

# Produce
Code the new functionality in TDD. Should be a piece of cake given the Prepare phase.

Being the primary beneficiaries of the testing and refactoring we do ourselves means more happiness. With a much better ROI on testing and refactoring, we're likely to a lot more of it.

Let's make this clear with a few examples. Not the least what I mean by QUICK and DIRTY tests

Johan Martinsson

Passionate about code design

Grenoble, France

View Speaker Profile