Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Stop Paying Back Technical Debt and Accumulate Technical Wealth

DZone's Guide to

Stop Paying Back Technical Debt and Accumulate Technical Wealth

If you focus on the surplus productivity you get from paying off debt, you have shifted your mindset towards wealth building.

· DevOps Zone ·
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

Remodeling software should be done with the same goals that we have when we remodel a house: to make it last longer and run better. Companies should be invested in mending their code to be able to get more productivity out of it. In order to get to this point, there needs to be a shift away from perpetually paying down technical debt towards building technical wealth. Within start-up culture, there needs to be a move away from just tearing down old code towards deliberately remodeling it.

The first step to doing this would be to rethink the way we define legacy code. A popular definition of legacy code is that it is code without test coverage. This definition, despite being incomplete, is better than the more widely held belief that legacy code is simply old and archaic. Legacy code, in fact, has nothing to do with age and has more to do with how difficult it is to change and improve. This definition of legacy code would include any code that isn’t cleanly written, has little explanation, or has no link to the logic and reason behind the decisions made in writing it. If there is no unit testing or documentation present, then you are probably looking at legacy code.

If you start thinking of legacy code as code that has no clues in it to indicate what the developer was thinking when they wrote it, then you will begin to see legacy code as the result of failed communication. This post makes reference to something called Conway’s Law, which states that your codebase will replicate the communication makeup of your organization. If you want to fix your problems with legacy code, you also have to address the problems within overall operations.

To fix your legacy code, you have to pay attention to the details that make code easier to work with in the future. This means proper and extensive test coverage, explanations for commits, and anything that will make it easier to understand what was going on in the mind of the developer at the time that they were working on the code.

However, legacy code is impossible to avoid completely. It will pop up for a variety of reasons. One of the most cited reasons is that in the early stages of the company, there's a push to put out new features, which overwhelms the need for maintenance. While this is understandable and even necessary for product-market fit, if this tendency goes unchecked, then you will hit a point where you can no longer fix your existing code and adapt to the future.

It’s the same logic you see in home maintenance. If you don’t take out the garbage or do the dishes or clean the floors, it will only get more difficult to do over time until you have to call a team in to haul out the mess that you’ve left building for months.

So, when CEOs complain that what used to take developers three weeks to push out to production now takes them 12, they are missing what we know to be developers battling with legacy code riddled with technical debt. For CTOs, it can be difficult to present the argument that their developers need to go back and work on existing code because it is not immediately apparent what the benefit of backtracking would be.

You're more likely to get your CEO, investors, and stakeholders to support this endeavor if you reframe it as building technical wealth rather than simply paying back technical debt.

Many start-ups focus so much of their energy on acquiring talent to build new features and keep innovation levels high but ignore what can be done to actually increase productivity levels, like paying back technical debt. If the debt had been paid off on time, what productivity would there have been left over as a result?

If you focus on the surplus productivity you get from paying off debt, you have shifted your mindset towards wealth building. This will move you away from a focus on the short-term to understanding the value of maintenance. For most start-ups, it is had to think past the growth phase, and stability is often looked down on. However, all that stability means is that you have the proper processes in place to keep technical debt at pay and accumulate technical wealth using that wealth on the right set of priorities.

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:
technical debt ,legacy code ,devops ,technical wealth

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}