Managing Code Quality and Technical Debt

by

Technical debt is often given a bad name in the development process. This stems from the fact that when it becomes a topic of discussion amongst developers, they are dealing with too much technical debt and it is causing serious issues in their code base. However, it is not always a bad thing.

When you start writing code, you are faced with two choices: either write it quick and dirty or do it the "right way". The quick and dirty route is often appealing because it delivers value quicker. From the business' point of view, it doesn't matter what is going on inside the code (in other words what the actual state of the code is) as long as it is delivering functionality to their customers. So if writing code the "right way" is more expensive and time consuming, it would not be obvious to a business stakeholder why they should choose this option.

While poorly written or untested code may deliver business value in the short term, if it left unmanaged it is not good in the long run. A code base that has not been developed the "right way" is difficult to maintain and will eventually develop some stability issues. This will make it more difficult for future attempts to add more business value to the code base. So by this standard, technical debt is the mess left in a code base after a series of quick fixes have been made.

How to use Technical Debt the Right and Wrong way
After looking at the above definition of technical debt you may be thinking that this type of debt is an inherently bad thing, but that is not the whole truth. At times the cost of taking on technical debt is less than the cost of releasing functionality at a later date but delivering higher quality code. Under these circumstances it is helpful to look at how the financial world treats debt as a useful tool.

If you mortgage a house after having studied how to pay it back, this is seen as a prudent use of debt and a useful investment. Saving up to pay the entire amount of a house upfront is not a feasible reality for most people. However, if you are continually using your credit card with abandon this is not a good financial practice. The same premise is applicable in software development.

If you need to release some functionality before Christmas it can be a good idea to implement something quick and dirty when the opportunity is big for success. However, if you start pushing out all features without taking care of code quality, architecture, and tests, you will start to see a slow down in processes and a reduction in the quality of your application.

The trick to balancing the costs and advantages of technical debt is to ensure that you have a strategy in place for controlling the debt that you take on. You should have a base standard for all the code that you release: this means that you by default write well-factored, flexible code with good test coverage. When you take on debt it shouldn’t be a decision taken lightly but should be taken deliberately.

The Consequences of Poor Communication
In order to implement a strategy like this you should be able to communicate the consequences of technical debt adequately. If your manager want feature X released in 2 days because it is more profitable by that deadline, and you are not able to communicate that writing the feature in 2 days will result in technical debt that will negatively affect future endeavors, your manager will walk away thinking that writing a feature is feasible in 2 days and that pushing developers to work at this rate is a successful approach. Not knowing what effects this deadline will have on the inner workings of the code base, your manager will begin to negotiate future deadlines based on this experience.

What the developer is grappling with in this scenario is a desire to meet business needs knowing that they won’t be able to adequately do so in either the short term or the long term. What should be done under these circumstances is communicate to non-technical stakeholders that short deadlines invariably result in shortcuts that will need to resolved at a later point in time. Technical debt is something that needs to be accounted for and managed, and this is only possible if all stakeholders in a project understand the consequences that come along with this debt.

Let’s assume that you have properly communicated the implications of technical debt to management; how do you then go about managing it?

Managing/Tracking Your Debt
Similar to dealing with financial debt, you need to know what debt you have taken on and how long it should take for you to get rid of it (even if you never intend on paying back all of it). In the story laid out above, where you need to release feature X in 2 days, it would be good practice to write a task for cleaning up the code base and writing tests in for the feature after it has been implemented. If you do this, then the debt that’s been acquired will be visible to everyone working on the code.

How you track technical debt depends on how you’re developing software. In agile, you already create new stories, so apart from your user stories, tasks, and bugs you will have an additional “technical debt” story. This will create much needed visibility on your technical debt and allow for you to know whether it is becoming a problem.

Apart from tracking technical debt while you create it, you may need to track debt as you run into it in the code base. This will either occur as you work on legacy code or as you undergo a large refactoring effort.

A great way of dealing with the tracking of your technical debt is to set aside a certain percentage of your time to solely working on technical debt stories. However, in order to do this, you have to make management aware of this and receive their approval.

Paying off your Debts
Talking about and tracking technical debt is not enough, you have to actually pay it back. You should set a schedule, where on a regular basis you deal with your technical debt stories.

In order to prioritize which technical debt stories you should work on first, consider the following factors:

  • Age: As with financial debt, technical debt accrues interest over time. The longer you leave code in a bad state the more damage it can have – it will create new bugs and people will have a hard time figuring out how and why things were done to begin with (bad code is notoriously obscure by nature).
  • Impact: There a difference in the type of impact technical debt can have on your code base. For example, a class that has come formatting issues is less of an issue than a subsystem that has no test coverage. Deal with the problems that have greater potential to cause more pain down the road. In the case of credit card debt, pay off the debt that has 20% interest before you pay off the one that has only 2% interest.

Once you’ve prioritized which debt to take on first, how do you go about actually paying it back?

There are several ways to do this:

  • Repay it entirely: replace or refactor it code until it is in a good state.
  • Repay it partially: instead of writing a good solution to pay back all your debt, you replace it with a solution that solely reduces the interest rate of your debt.
  • Don’t repay it all: Only deal with the interest on your debt. This is particularly useful when the technical debt you have isn’t particularly costly, and the code that it effects is hardly changed and too costly to replace.

Technical debt is never entirely avoidable, but having a good strategy in place to manage it is necessary to implementing it as a tool effectively.

To read the full post visit here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|