Design Debt: Ramblings

26 Jun 2007

Just reading Chris Sterlings recent post titled Clean Up, Clean Up, Everybody, Do Your Share* *and the following snippet on design debt caught my eye.

Have you ever been part of a legacy project where it seemed almost impossible to add the feature asked for because you weren’t sure what will break once it is added?

A resounding yes and it’s a tricky situation to work your way out of. You’re often without any substantial unit or regression tests and are left fighting an up-hill battle on two fronts. On one hand, you’re trying to devise a design that’s going to have the least impact on pre-existing code (perhaps through a facade if you have enough knowledge about expected behaviour to be able to pull a suitable abstraction) while on the other your level of frustration has reached the point of wanting to go down the rabbit hole of gutting and re-writing (emphasis on re-writing and not refactoring) components. It’s situational about which approach is the right one to take but there’s a definite time and place for fairly serious refactorings. You can only cart around technical and design debt for so long.

This does not mean that we no longer conduct design sessions to determine a design direction for implementing a feature but these sessions should produce just sufficient enough design to get started. Also, as a team we should decide if an artifact needs to be captured from our design session.

The context for this note is around the need to hold design sessions/reviews even when working in an environment that encourages continous refactorings. On a similar vain you don’t want the very notion of a design session or review to forbid or discourage refactorings during the course of an implementation. I strongly agree that design sessions are means to influence a direction, not dictate one. If as an implementor you come across a snag in your initial design, please don’t leave it and use the excuse of ‘oh it was in the original design and it was approved‘ when someone calls you on it. That excuse worked in University but certainly doesn’t fly in any environment I’ve seen.

Chris talks in more detail about various forms of accumlated debt and some strategies for dealing with it in agile environments, I just picked out the pieces that particularly struck home.

So, there you have it. Dealing with legacy components is often difficult but necessary, design at an appropriate level of abstraction to influence (and not dictate) direction and lastly… don’t make excuses