Metrics to Minimizing Technical Debt

I have found throughout my development career that tracking the listed metrics below can help minimize the amount of technical debt in a solution while keep code clean and readable.

1. The framework versions of each project within an application or solution.

Reason it’s important?- When your projects have fallen behind a version, your team is not able to utilize the latest language and framework features and third party packages cannot be upgraded. Eventually, if your projects fall multiple framework versions behind, the complexity to upgrade to latest version of the framework increases significantly. The documentation starts to become limited, support is dropped, and eventually your team is forced to upgrade with little to no time until a deadline.

Solution to minimize debt - Create a sheet with the names and framework versions of each project for all of your solutions. Stay informed of when new framework versions become available and make upgrading the framework version a required part of your development sprints.

2. The number of third party software packages?

Reason it’s important - Each time you reference a third party library your organization becomes dependent upon the technology. If it is an open source project that is abandoned, then your team will be left with little time to find an alternative. Sticking with an abandoned third party library will also prevent your team from upgrading framework versions. This will eventually lead to a large amount of technical debt that can be difficult to overcome. The project may need to be completely redone if this is not addressed quickly.

Solution to minimize debt - Try to limit the number of third party packages used in your project. It is understandable to want to save time but that could cost you later on. If you must reference a third party library, make sure that the project has a large and active user base with a roadmap for the future.

3. The number of projects in an application

Reason it’s important - If you open an application that has a large number of projects the solution can take a long time to load and build. Worse the application appears to have an overwhelming complexity that is just unnecessary. Upgrading framework versions and package references takes more time and effort. Developers may become confused about the project separations and will be less productive trying to identify where their code should be placed.

Solution to minimize debt - Try to limit the number of projects in a solution to under 5. This allows for UI, Domain, Infrastructure, and unit test projects. A Clean Architecture such as ports and adapters can be used in the majority of situations and can be accomplished with under 5 projects.

4. Number of lines in each class and method

Reason it’s important - Too often developers are in a hurry and do not consider the length of a class or method. The classes become so large that they are unreadable. When developers who did not write the code are asked to make modifications their productivity is very low. This is because there are no abstractions and reverse engineering every detail of the system must be done to understand the logic.

Solution to minimize debt - Strive to keep all classes under 500 lines and all methods under 30 lines. Follow the Single Responsibility Principle by making sure each method is doing only one thing. This keeps the code clean, readable and testable. A developer is able to scan the code and quickly identify the purpose of each method or class without having to know every detail of the system. This allows the developer to work more efficiently ignoring details of the methods they are not concerned with while focusing on the part of the code that needs to be changed.

5. Classes that do not use constructor injection or dependency inversion

Reason it’s important - Not using dependency inversion, interfaces and ioc containers reduces the ability to test different scenarios that the unit you are building may be exposed to. Developers will end up missing important logic that leads to bugs because the code is too coupled. This is due to that fact that it will take too long to setup different test scenarios because the dependent classes cannot be mocked.

Solution to minimize debt - Use an ioc container and constructor injection whenever possible. Always use interfaces instead of direct references to a class.

6. The unit test coverage

Reason it’s important - This one should be obvious. As new requirements come in and old requirements are updated the code base changes. Without proper test coverage making changes to legacy code can lead to a significant amount of bugs. The development team can get into a never ending cycle of trying to update the code to fix a bug only to create multiple new bugs.

Solution to minimize debt - Maximum the number of methods that you test. If you have the skill and time utilize test driven development. This will not only lower the number of bugs in the software but will also allow developers to refactor code in the future with confidence. Unit tests can be run after every checkin and catch bugs introduced to the system.