Question

I am currently studying test driven development. I am inquiring about an improvement in design if we refactor after the development of every couple of units as opposed to dedicated refactoring sessions that are more spaced apart in time.

I am aware that the technical debt will be larger. But I am wondering what other impacts. Maybe the refactoring process is not as effective when there is a larger time interval because…?

Thank you..

Answer 1

A beneficial collateral effect of applying TDD is that your design tends to be thinner and sounder. So major refactorings become unnecessary. In my opinion, this is the effect of designing the system by tests, from “top” to “down” (where “top” are the external interfaces, constraints and requirements, and “down” are the internal implementations and contracts). Sometimes I’m even confused by TDD meaning “test driven design” instead of “development“.

Thus, redesigns are driven by changes in constraints and requirements, not by technical debt, which is mitigated at the innermost interfaces. The scope of the changes will determine the extent of the refactoring — if this is true, “major” refactorings are expected only when the topmost interfaces change.

You mentioned planned refactorings as a step in a longer term development cycle. I think this is a fragile strategy, not because we shouldn’t clean technical debt — we should do it as soon as possible, and that’s a practice at the core of TDD –, but because it’s risky. To illustrate: in order to plan your refactoring step, how would you assess the size of the technical debt? What if the estimated refactoring time is not enough? Will the system be healthy if you cut the refactoring to do other important things? These are important questions, and not the only ones regarding technical debt management. From a risk management perspective, TDD means better control.