MARTYHAUGHT

Lately I’ve heard a lot of folks talking about technical debt. There’s an angle on this discussion that I haven’t seen highlighted much. Most of the talk centers around the team either knowingly or unknowingly taking short-cuts and writing bad code. Martin Fowler does a nice job of defining these different types in his technical debt quadrants post. Uncle Bob Martin follows up with more thoughts on these types of debt. I agree largely with what both are saying. So what do I think is missing?

The type of debt that was once beautiful, well-refactored code but grows into a bloated, ill-fitting mess. The transformation does not happen because code gremlins get in and wreck things. No, it’s the ever changing business needs that are to ‘blame’. I’ve seen this happen on a couple of my projects right before my eyes. We were a full on XP shop that had great code coverage, pair programmed and refactored with the best of them. Our initial design fit the original problem but as things shifted the design didn’t seem so appropriate as months passed by. What may have been a beautiful, elegant solution became unwieldy and bloated.

This new kind of debt can not be avoided no matter your process. It is inevitable if you are in a business where the needs change. No practice or oracle can keep it from becoming a reality. One of the reasons for it is the change is so subtle that you don’t realize you now have technical debt until it’s there staring at you.

There is an analogy that I feel fits this situation well. Your code is a garden. Over time, weeds will grow and plants will spread into places you did not intend them. You’re just fooling yourself if you think you can stop weeds from growing. No, as a gardener you need to tend to your garden by pulling the weeds once notice them. It’s a process that you do regularly. If not the weeds get bigger negatively affect your garden.

As with the garden, your codebase will grow its ‘weeds’. They may take shape by a shifting feature that leaves functionality unneeded or overly complex. Maybe it has encumbered other parts of your system by its existence. Once that code no longer provides value it must be weeded out. Delete away. Worry not as you have version control right? If it needs to come back so be it but then you’ll do so in a clean, concise manner.

Another similar analogy is the Bonsai tree. This little tree will grow over time. When you brought it home it was beautiful with its perfect shape. As it grows that shape will not stay as beautiful. It may become leggy or grow in a direction you don’t want. As it grows slowly, you won’t notice it as much unless you’re looking carefully. All the sudden you see that one of the branches seems unbalanced with the tree’s shape. The solution is clear, if you want a Bonsai tree to keep a certain shape you must prune it. You must actively shape its branches.

Your code is like a Bonsai tree too. It will naturally grow over time. This is not the radical change where features are being removed or functionality is significantly shifted. Months of incremental changes will add up to the point where you’ll look at a set of classes and see that they no longer feel as fit as well as they once did. As with the Bonsai tree your code has a shape and you will need to prune it to keep its desired shape.

Both of these types of code debt happen and to good teams. It doesn’t mean you’re cutting corners or ignorant of good design. You can’t stop the weeds as they’re too sneaky but you can be vigilant to when they become apparent. My experience has reinforced for me that your code is like a garden and that as things change, you will need to be ready to weed out the technical debt that just sprouts up.

blog comments powered by Disqus