4

Lets say i'm a new guy coming to the project, how do I clearly determine if there is a debt on the project? What will show it to me? Lets say a certain amount of TD exists at any project. So the next question is: how to measure it? How to quantify the amount of technical debt? Without resorting to metrics (like code coverage, etc.) how can an "outsider" see if the amount of technical debt is big or not?

A similar question would be: let's say developers are writing "dirty" code which resolves in unconscious technical debt. How would one determine that the amount of the technical debt has suddenly increased on the project? How would it come on sight?

Improve this question
4
  • Technical debt is very subjective, so unfortunately I've never seen a way to quantify it precisely.
    – GHP
    Commented Mar 29, 2018 at 11:44
  • 1
    Technical debt is exactly everything the team wishes they had time to that isn't a feature. It is the sum total of non-functional requirements not met.
    – candied_orange
    Commented Mar 30, 2018 at 4:05
  • 1
    I think you have a fundamental misunderstanding about the Technical Debt Metaphor. Writing "dirty" code is not Technical Debt, that's just bad programming practice. Technical Debt means that you write the best, cleanest, well-factored, well-designed, maintainable, sustainable, simplest code you possibly can, given your current understanding of the system. However, while writing the code, you gain a better understanding of the system, and then you refactor to make it look like you had that better understanding from the beginning when you started writing the code.
    – Jörg W Mittag
    Commented Mar 30, 2018 at 6:25
  • 2
    Technical Debt is the difference in the level of understanding of the system between when you started writing the code and after you learned more about the system through the act of implementing it. In other words, Technical Debt is the missing experience that you are going to gain throughout the project. Technical Debt has nothing to do with "dirty" code. Quite the opposite: Technical Debt requires clean code, otherwise it is going to be hard to pay it back through Refactoring, if your code is an unmaintainable mess!
    – Jörg W Mittag
    Commented Mar 30, 2018 at 6:28

2 Answers 2

Reset to default
2

I'd go with the following for a gut-instinct:

  1. What is my test-coverage?
  2. Are there manual test-cases for additional testing?
  3. What does the bug-list look like?
  4. How many bugs do people think are not in the bug-list?
  5. How complicated is the external configuration?
  6. How many external applications does it depend on?
  7. How recently has it been updated?

You're looking for:

  1. 70% - 80% test coverage can be a good sign.
  2. Rigor in documented testers is a very good sign, and rare.
  3. Detailed, organized, and recently updated bug lists is good.
  4. All bugs that we know about are put into the list by process.
  5. Little to no external configuration.
  6. Fewer is better. Databases and caches are typical. More tools mean more risk / potential for debt.
  7. Recent updates mean new features or bugfixes. Do you see evidence of bugfixes in the repository logs?

It's a gut-call, but you can figure this out in a day or two. More work is required for more details.

Improve this answer
2
  • Thank you for your reply i find it very helpful. Thou could you please clarify what do you mean by external configuration?
    – Andrew
    Commented Mar 30, 2018 at 7:00
  • Configuration of services / applications can be stored in config files, environment variables, or some other local storage (registry?). If the program heavily depends upon the config files, and you don't see any obvious management of this information - you've got some code-smell building up.
    – Kieveli
    Commented Apr 4, 2018 at 16:28
2

There are really two ways to measure it, from my perspective, each with limits.

Measuring directly using tools

Code coverage tools, defect / bug backlog, outdated dependencies, etc.

Benefits:

  • Direct, objective, monitorable measurements
  • Can be misleading if taken too literally. Increasing bug count from 1 to 2 does not mean technical debt has doubled. But 200 open bugs versus 100 open bugs suggests a lot more debt.

Downsides:

  • Very incomplete - there are many forms of technical debt which this misses.

Measuring Indirectly

Ultimately, technical debt is anything that gets in the way. So we can define technical debt as things which hold a team's velocity back from being more.

So an indirect way of measuring technical debt is to pay some of it back and compare the velocity over time. If technical debt is repaid, velocity may temporarily drop, but then rise back up to higher than before. Otherwise, it will gradually increase over time.

This is indirect because it doesn't really tell you how much debt you actually have at any particular moment in time, but it shows you improving or not, which is likely ultimately what you want.

Improve this answer
1
  • Yes, measuring velocity or time that it takes to perform the task would be probably the best way to measure the amount of the debt.
    – Andrew
    Commented Mar 30, 2018 at 7:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.