Clean Code : Technical Debt Is Not Real

Everyone, some more then others, will have faced the dreaded task of being forced to 'clean' something. Usually their room, maybe the garage or an attic. These places are all perfectly suited for storing things, stuff, junk. Until your favorite empowered entity, decided it was getting too cumbersome for you to find things in there. You put in a lot of 'work'. Yet in the end all you get is "you call that cleaning up?"

For code this is the same. By your standards code may be easy to 'clean', 'order' if you like. Others however likely won't see it that way. Find out why this is key in understanding the source of technical debt.

A State Most Rewarded

In our childhood we have all created a simple 'defense strategy' against "Clean your room". Stick stuff in drawers and boxes, "out of sight, out of mind". Not many kids would apply any more vigorous strategy to it. What toy went where never mattered. And it is a seemingly efficient method to clean up.

Later in life we still cling to this approach dearly. We've been rewarded for it so often. It must be working! We have been conditioned to become experts at passing a quick inspection. Not a thorough investigation. The room 'looks' clean, parent(s) happy, result achieved, perfection.

"Perfection is the harmony of things, or the state where everything is worthy of being observed, that is, the state of agreement [ consensus] or identity in variety; you can even say that it is the degree of contemplatibility" Gottfried Wilhelm Leibniz

Using Perception

The human mind is still the most powerful visual recognition tool available. People can identify others by appearance, posture, the way they walk, the list is extensive. This has thought us, that to find something in the real world. You create a situation that allows this visual process to perform efficiently. Kids can easily create this situation. Throwing a whole box of Lego on the floor just to find the one piece they wanted, usually within seconds. The human mind will sort and order arbitrarily. Even parts refactoring can be done by simply looking at line width and code density.

Creating Consensus

When it comes to writing code however, all forms of chaos must be banned to the nether realm. Tools can be used to create a sense of measurable order. Among developers a consensus is reached on how to define this desired state. Coding guidelines, logical constructions, patterns, may all be implemented. You end up with 'clean' code. A syntactical narrative that is a repeating pattern throughout. The name tells you what it does. The code tells you how it's done. No comments required.

Only endless repetition of the same pattern can guarantee the survival of this order. There should be no obstacle for developers to stick to this commitment.

How is technical debt still possible?

A State Most Revisited

We have been conditioned to stop at a level or order that unlocks the reward. As we've established, the mind only required a basic level of order to achieve our personal objectives to begin with. Given the wiggle room or the 'personal interpretation' of the team consensus. Nobody intentionally creates technical debt. Situations just naturally present themselves wherein the reward is unlocked at a level that does not meet the overall standard. And so we create a little bit of local chaos, that in the long run makes it impossible to maintain overall 'perfection'. Things become less worthy of being observed. And we forego the ability to contemplate their functionality or role within the grand design.

Technical Debt Still Is Not Real

"Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit, such as making a release" Martin Fowler

We have to accept there is always a better way to do things. And we should plan ahead to be able to embrace this. Part of agile is making the best decision with the information available at the time, without foregoing the option to change your mind in the future.

More importantly, enable others to implement these changes. As long as the door remains open to making improvements. Or being able to reduce 'local' chaos. The state of perfection can be maintained. If you close it along the way, it is like embarking on the road to dead code. You are heading toward selling that big refactoring/rebuild action to your manager. You have traded reaching your long term goals for a short term benefit.

Never stop throwing stuff in boxes!

I apologize for the simplicity of this statement. Yet as long as you can keep throwing stuff in boxes. You maintain the option to change the situation later. Call it classes, functions, micro-services, pick something that you find acceptable that enables your code to move on. The choice should focus on not making a choice. Accept that your ability will be outmatched by others and even your future self.

TL:DR;

Technical debt is the result of our personal flexibility in regards to the team level of order. We accept local chaos in return for functionality in a shorter time-frame. As the variety of solutions rises. Local chaos makes it impossible to maintain overall 'perfection'. Hence a desire to restart the cycle emerges. Resulting in either mass scale refactoring or starting over from scratch. Technical debt therefore isn't real, it is subjective. Poor architecture, lack of ability and short term vision can make it a 'reality'. Only because you choose to accept that latter instead of work on the former.

Bonus: Technical Debt Metaphor Revisited

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

The original metaphor as coined by Ward Cunningham. After reading my post, hopefully you see the obvious way out. A messy way that makes things harder in the future is a commitment. It closes the door to embracing future change. If you do not want to incur technical debt, you can simply strike these solutions off the list. You can write as messy a coded solution as you wan't, just don't make any commitments. Contain it via the correct patterns. Constrain your solutions to implementations that do not make any far reaching commitments. When absolutely required, opt for the cleaner approach instead, as you are changing architecture.

Further reading:

• Martin Fowler : Technical Debt
• Martin Fowler : Technical Debt Quadrant
• Uncle Bob : A Mess is not a Technical Debt

Feel free to comment or contact me for any questions or remarks you might have. This article is not for recruitment purposes. The views and opinions expressed in this article are those of the authors and do not reflect in any way those of the institutions or organizations to which he is affiliated.