Technical Debt

Tags:
2022 01 01 head

The technical debt or code debt is a concept in software development that reflects the implied cost of additional rework. The rework is caused by choosing an easy limited solution now instead of using a better approach that would take longer to realize.

Another source of technical debt is natural technical obsolescence.

As with monetary debt, if technical debt is not repaid, it accumulates interest, making it harder and harder to implement changes.

Unaddressed technical debt increases software entropy.

Spiraling out of control entropy is the death of countless software solutions over the last century.

Similarly to monetary debt, technical debt is not necessarily a bad thing. Sometimes, as e.g., a proof-of-concept is required to move projects forward.

Some experts claim that the technical debt metaphor tends to minimize the ramifications, resulting in insufficient prioritization of the necessary work to correct it.

Shipping first time code is like going into debt. A little debt speeds development as long as it is paid back promptly with a rewrite.

The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.

Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

— Ward Cunningham
1992

How to Eliminate Technical Debt

  • Use static analysis tools to detect technical debt in your source code.

  • Use the features of your IDE [1] to perform simple refactorings and improve the quality of your code.

  • Use your IDE to find all TODO comments

  • Use your IDE to find and remove commented-out lines of code. Git was created to keep track of your modifications. Keep your source code free of obsolete and unused code.

  • Use a Gradle Build Tool plugin [2] To update your libraries and remove technical obsolescence.

  • Please use the current version of your technical stack and build toolchain.
    Update your Java version when the next one is coming out. You have access to better libraries, interfaces, and runtime engines. Known security flaws were corrected. Defects were removed.

Each technological stack is gifted with open source and commercial static analysis tools.

SonarLint supports all major languages and development environments. You will find a list of tools for static code analysis for all major programming languages.

A professional software developer shall use these tools to validate and improve her source code.

Should You Reimburse?

2022 01 03 technical debt

We learnt this lesson during our economic training in college.

A little debt is OK.
Big debts will poison your life and source code.
Big debts are cumbersome to repay.
You need efforts and time for a payback.

The lesson is to close your debts before they are too big to be managed.

You will otherwise bankrupt either your bank account or the source code of your application.

Preventive maintenance is a learnt technique for technical products.

How to Measure Technical Debt

Here are some approaches to quantifying the technical debt of a product.

New Bugs versus Closed Bugs

Every known bug is essentially a tiny sliver of technical debt. If you want to know your total debt, it is important for your engineers to keep a tally. Assuming your engineers make a note in git when bugs are fixed, you can calculate how effectively you are managing your technical debt. If new bugs are outnumbering closed bugs, you need to make some changes.
Zero bug policy [1] nicely reimburse this technical debt.

Code Quality

Complex code is a sure sign of growing technical debt. At some point, someone is going to have to unravel that mess. Code quality is an aggregation of several metrics that quantify the overall quality and complexity of your code:

  • Smells and potential errors are detected through static analysis tools

  • Cyclomatic complexity, method size, class size

  • Class and package coupling

  • Depth of inheritance
    Continuous fitness functions [1] based on static code analyzers are the way to detect this technical debt cite:clean-code,clean-coder,clean-architecture].

Cycle Time

This measures the amount of time that passes between the definition of the change, the first commit, and deployment. You need to study the time it takes to make changes to existing code and to solve problems without using quick fixes. If your engineers are spending hours fixing small bugs, you know that there is some technical debt lurking in your code.
Your agile and Scrum tool provides cycle time data [4].

Code Coverage

In a sense, the code coverage metric looks at the same issue from the opposite direction. In this case, you are measuring how much of your code is executed when you run your testing suite. The more lines that are unused, the more likely it is that you have poorly written code.
Code coverage tools such as Jacoco provide these values [3].

Code Ownership

If you get too many people working on the same tasks, you can easily end up with a steaming pile of cruft. That said, you do not want only one engineer taking ownership of an entire project. If they get sick or leave your organization, it is game over.
Social aspects can easily be measured in a code repository [2].

How to Continuously Improve

A powerful approach is zero defect source code [1] approach.

2022 01 03 retrospective

You can start very simply.

  1. Track locations of technical debts with TODO and FIXME comments as a first step.

  2. Next time you have to modify source code in a package, use your IDE features to find all TODO in the package you are working on.

  3. Fix at least one such comment and improve the code.

  4. Repeat, and over time, your technical debt will slowly diminish.

Fixing technical debt is not rocket science. It means to have discipline and behave like a professional software developer.

Lessons Learnt

Technical debt does not appear overnight. Debt increases slowly but steadily. Big debt clearly shows the organization was unprofessional.

Investing a small amount for continuously improving your source code base is the most effective approach to avoid technical debt.

  • Use an actual version of your technology stack.
    You must anyway upgrade your stack if your product is under active development. So why do you wait and lose capabilities to improve?

  • Update monthly the libraries you use. Updates often close security vulnerabilities in your code. You have a legal responsibility to secure your code and protect your users.

  • Use the static quality checkers and refactoring features of your development environment.

  • Only refactor code you have to change.

  • Apply the boy scout rule [2, 3]. Leave the code in a better state as it was when you started.

  • Train your developer in refactoring and clean code practices [4, 5, 6]. Beware, technical debt is also created through:

    • Lack of knowledge when the developer does not know how to write elegant code,

    • Lack of ownership with outsourced software efforts results in in-house engineering being required to refactor or rewrite outsourced code.

Professional software developers deeply understand the impacts of technical debt.

Amateurs just ignore the consequences and hop for the next product before they go bankrupt.

Links

References

[1] N. Ford, R. Parsons, and P. Kua, Building Evolutionary Architectures: Support Constant Change, First. O’Reilly Media, 2017 [Online]. Available: https://www.amazon.com/dp/1491986360

[2] R. C. Martin, The Clean Coder. Prentice Hall, 2011 [Online]. Available: https://www.amazon.com/dp/0137081073

[3] R. C. Martin, Clean Craftsmanship. Addison-Wesley Professional, 2021 [Online]. Available: https://www.amazon.com/dp/B095C16LSW

[4] M. Fowler, Refactoring, Second. Addision-Wesley, 2018 [Online]. Available: https://www.amazon.com/dp/0134757599

[5] J. Kerievsky, Refactoring to Patterns. Addison-Wesley Professional, 2004 [Online]. Available: https://www.amazon.com/dp/0321213351

[6] A. Scott and P. J. Sadalage, Refactoring Databases. Addison-Wesley Professional, 2006 [Online]. Available: https://www.amazon.com/dp/B001QAP36E

1. IntelliJ IDEA IDE has a powerful set of functions to detect code smells and perform automatically standard refactoring activities. The SonarLint plugin for various IDEs to detect quality and security issues in your code.
2. I use the com.github.ben-manes.versions for this purpose. The plugin nicely handles multi-modules projects. The plugin also supports the central declaration of dependencies feature in Gradle.