One effective way to improve code and lighten the workload of developers is to address tech debt. While there many ways to define tech debt (and we're working to solve them all!) we find a few fundamental metrics can have great benefits without significant refactoring effort.
Set up the repository
- Complexity
- Click to expand the Complexity panel
- Define the current repositories threshold for Excessive Complexity
- Set a Target to address - what percentage of the files over the above threshold are you targeting to reduce complexity on?
- Set an estimated time to address - how long would you expect a developer to spend simplifying or breaking down an overly complex file?
- Duplicate Blocksare blocks of code that appear more than once.
- Set a target for what percentage of duplicate blocks you would like to de-duplicate.
- Set an estimated time to address - how long would you expect a developer to find the duplicates and consolidate to a single block of code.
- Test Coverage
- Set a goal for Unit Test lines per Line of Code
- Very good coverage is 1:1
- A new repository with little testing may have next to nothing for test lines.
- Set an estimated Time to create unit test.
- Set a goal for Unit Test lines per Line of Code
- Line Level warnings
- Set an approximate time fix a line level warning
- Select the percentage of warnings you aim to fix in each category
- Developer wages
- Set an average loaded cost per developer per day. This is used to calculate the cost of work to address the target tech debt.
- Languages
- Toggle the languages you would like to to include/address in the tech debt total.
Reading the results
- Days to fix
- Check the 'Days to fix' section to see an estimate of how long addressing each of the Tech Debt Indicator categories requires.
- Cost to address
- Technical Debt Total is a dollar value based on Days to fix and Developer wages
- Cost per Line of Code is the total divided by Lines of Code. Under $3.00/LoC is a good target.