SonarQube is a software product which runs various coding style rules and other metrics similar to FxCop or Re-sharper. It defines breaking the style rules as:


This is commonly referred to as technical debt. Issues associated with maintainability are named “code smells” in our products."


However, I would normally think of technical debt as "A piece of code which doesn't follow the overall architectural pattern."

For example, say we have a business rules layer, but as a quick fix we put one bit of business logic in the UI layer.

Or, say we have a project which is very OOP, but we add a procedural helper class for a new feature.

The code might well meet all the style rules, have no duplication etc and be fine on its own. Its only considered technical debt because it doesn't fit the pattern of the other code in the project. In order to make the project 'nice' again we need to go back and refactor it so that everything works the same way.

I would think that this kind of difference would be hard to pick up with code analysis rule sets and it seems disingenuous to call style rule violations "technical debt".

Am I wrong or right? Do some objective rules or some class of rules make a good definition of technical debt or at least a type of technical debt?


this tool will tell management that a line of code


Is 2min worth of tech debt. Which seems wrong.

However, it will also do the same thing for cyclomatic complexity or duplicate code. Which seems less wrong.

  • 9
    I think most static analysis can give you is general idea of where and how serious problems are. But it is not precise enough to give you some value of how bad it is. Code analysis is tool for developers to get insights into their codebase. It is not tool for managers to plan or estimate.
    – Euphoric
    Commented May 22, 2017 at 21:04
  • 1
    Would you consider code duplication technical debt? Or the usage of magic numbers? Dead code? Unused variables? These are objective rules you will find in Sonar's default profile and FindBug too.
    – Laiv
    Commented May 22, 2017 at 21:17
  • Possible duplicate of How is technical debt best measured? What metric(s) are most useful?
    – gnat
    Commented May 22, 2017 at 21:29
  • 7
    @Ewan The question that gnat's question is a duplicate of probably more useful and explicitly discusses SonarQube. Technical debt is intentionally loosely defined and any tool that "measures" it is simply redefining "technical debt" to conveniently be the sort of things the tool measures (and fits the creators' biases). This is not to say that the metrics are unrelated to technical debt, but that they can give both false positives and false negatives. Commented May 23, 2017 at 0:18
  • 2
    You are overthinking and taking a advertisement too seriously. Technical debt is a big thing in software engineering, sure to grab any developer's attention. If you do analysis tools and any of your features come close to what some people may qualify as technical debt, you 'd better make sure as hell to put it on the box, to name it as a feature. Commented May 23, 2017 at 6:55

8 Answers 8


That is a hard question.

On one side Ward Cunningham originally used it to illustrate the difference between a theoretical waterfall model and an iteration-based incremental development model. If you only start writing your code once all possible requirements are known, all architectural decisions and plans are done, everything to be coded is already perfectly optimized, and so on ... you will have the faster and most efficient code writing possible, with no waste and no maintenance problems (also probably having no need for maintenance since all possible requirements were known before development started). But, at the same time, the whole process will get very-very long and in a real-life project where requirements can change over time, this might not even be possible, even on a theoretical level. On the other hand, the incremental development model lets you start coding earlier, deliver earlier, adapt to changing needs and newly discovered requirements faster. Which Cunningham argued to be a better process by leading to the most appropriate product in the shortest time. But, also has a risk if you do not maintain your code when new information becomes available, which can lead to problems.

As such he was not writing about bad code quality, he assumed developers will try to do the best possible job they can in both processes. From this point of view you would not even need to look at the code if it is not developed in a waterfall model (being somewhat of a non-real-life tool where every requirement is known upfront), but in iterative/incremental/agile/etc... ways it most probably has technical debt.

On the other hand, research on this topic has already shown, that the tools currently available use different definitions for code quality (and so technical debt), measure different properties, give results that might not correlate, the severity of found issues might not relate to their real severity and the estimated fixing times can be off by a multiplier of 20.

And to make the situation a bit more interesting, we also have to acknowledge that the code analysis tools are also software products, that are under development: on the exact same code using different versions of the same detection tool, some releases might report lower numbers thanks to bugs being fixed or detection algorithms becoming better, some releases might report larger numbers when detectors for new issue types are added.

Our research on this topic (also contains the citation of research I mentioned above): https://www.researchgate.net/publication/357875475_Reproducibility_in_the_technical_debt_domain

  • sorry i didnt see your answer for so long. I guess if we define technical debt as a design difference between optimal if written from scratch when all requirements are known. and current. then we have a clear answer that if code analysis cant detect the requirements it cant detect the debt
    – Ewan
    Commented May 25, 2022 at 10:12

Can technical debt be detected by code analysis?

This is like asking if a speedometer will make you a safer driver.

However, I would normally think of technical debt as "A piece of code which doesn't follow the overall architectural pattern."

Technical debt has many more faces than that. The metaphor is about borrowing time from your future self. Just like driving, there are many ways to get into trouble that the tool simply won't help you with. But that doesn't mean the tool is useless. Paying attention to it can help. It's just not everything.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Technical debt is commonly associated with extreme programming, especially in the context of refactoring. That is, it implies that restructuring existing code (refactoring) is required as part of the development process. Under this line of thinking refactoring is not only a result of poorly written code, but is also done based on an evolving understanding of a problem and the best way to solve that problem.

Technical debt may also be known as design debt.


Uncle Bob will tell you that the quick gains you get by procrastinating design is no excuse to make a mess.

Fowler will argue that some debt is prudent, some reckless, and some accidental.

Cunningham seems satisfied as long as you pay down the debt to make room for a new feature before adding that feature.

All I care about is if you're making your fellow programmers miserable. I've been in development environments where change was fast and easy. Others where it was excruciating and glacial. The big difference had nothing to do with having, or not having, a tool that wagged it's finger at you when your design was weird.

The biggest thing missing from this tool is an ability to call out bad names. Give things bad names and you're in for a world of technical debt. Bad names are loan sharks that charge staggering interest and want you to pay every time you look at them. How's a tool going to spot that? Best thing for this is asking a fellow developer if the name makes sense.

Am I wrong or right? Do some objective rules or some class of rules make a good definition of technical debt or at least a type of technical debt?

Does obeying the speed limit make me a good driver? Would you like me to stop doing donuts on your lawn at 25 miles an hour?

Or as explained by a 5 year old: "Does this bug you? I'm not touching you."

This thing might help, but not if you think it takes care of everything.

  • sorry, which style rule do you think define tech debt?
    – Ewan
    Commented May 23, 2017 at 7:25
  • @Ewan as said in that answer : Technical debt may also be known as design debt.. Technical debt is way more offer a problem of design than style. And with "design" we can include naming problem by the way.
    – Walfrat
    Commented May 23, 2017 at 12:13
  • I agree with the views expressed in this answer, but I don't think it really addresses my question. Either some rules do indicate tech debt, in which case please show examples. Or no rules do, in which case show why your definition of tech debt can only be evaluated by a human. I'm not saying "style rules have no value", I'm questioning the branding of them as tech debt indicators
    – Ewan
    Commented May 23, 2017 at 12:19
  • 4
    "Does this bug you? I'm not touching you." What an excellent explanation of the feeling of technical debt for non-programmers! Commented May 23, 2017 at 15:50
  • “Technical debt” wasn’t necessarily easy to implement in the short run. Instead of some nice clean code that doesn’t work it could by one big pile of mess that doesn’t work.
    – gnasher729
    Commented May 25, 2022 at 5:25

You can use CppDepend to create easily your own rules using CQLinq, the rules can concern the architecture, design and the implementation. Including the coupling between projects, types and methods. And you can specify your technical debt for each rule as described here http://www.cppdepend.com/technicaldebt

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 10
select new { 
   Debt = (3*(m.CyclomaticComplexity -10)).ToMinutes().ToDebt(),
   AnnualInterest = (m.PercentageCoverage == 100 ? 10 : 120).ToMinutes().ToAnnualInterest()
  • yes, but my question is really about whether 'technical debt' is an acceptable term to use or not
    – Ewan
    Commented Jun 18, 2017 at 8:25
  • technical debt is a measure that can't be in any way an out of the box feature from a tool, you have depending of your context to specify the technical debt of an issue and review after some iterations this value. If you use a tool with the predefined values, it's not interesting at all. But if you calibrate this measure depending on your context, it could give you a good idea about the code quality and the debt of a project. Commented Jun 18, 2017 at 9:42

There are all sorts of things that could be technical debt. Not following coding standards is probably the least of them.

Huge files and functions are a problem, and static analysis tools can flag them.

But the thing tools won't really help with is an over- implicated and undocumented mess of code, where nobody knows how it works any more. People keep tacking more bits on to fix problems, relying on ever more tests to check they haven't broken it.

  • Huge files and functions may be or may not be a problem, but usually don’t stop you from working with your code base. Unless you have a compiler that can only process source files up to 100KByte, in that case a file with 99,990 bytes is technical debt.
    – gnasher729
    Commented Feb 10, 2022 at 22:57

There are trivial cases: My compiler will tell me when I use a deprecated function, that is a function that works today, but is outdated, and will go away. You won’t be able to avoid fixing that code, so it’s technical debt.


There are trivial cases: My compiler will tell me when I use a deprecated function, that is a function that works today, but is outdated, and will go away. You won’t be able to avoid fixing that code, so it’s technical debt.

That’s technical debt: Work that you will have to do at some point in the future, when low code quality makes working with your code base expensive.


As a developer, you have to write code that works (which can be more or less difficult depending on the situation) and then you have to avoid stupid bugs. Unit tests are very, very good at finding stupid bugs at almost zero effort. So very useful during refactoring where there is a risk of stupid bugs, but totally useless for all the geniuses who never, ever in their life make stupid mistakes :-) That's a situation where unit tests won't save you time immediately, but in the long term. And if you write unit tests anyway, it's most effective to write them with the code, because you know the subject at that point.

Unit tests are also very, very useful in situations where a solution is hard to find, but easy to verify. In that situation unit tests may be unavoidable, because you can't get your code into a state where it works correctly without verifying the results.

Another situation where you need unit tests is when you have complicated rules that need to be followed. Like handling Unicode correctly can be quite complicated - you can then write unit tests that specifically test for the hard cases and it forces you to write code getting these cases right.


Your understanding of techinical debt is slightly off.

Technical debt is anything that makes maintenance more difficult than necessary. It can range from trivial issues like bad variable names and inconsistent formatting, to severe architectural problems, missing documentation, or lack of automated processes. Anything where you pay an ongoing cost (in development time and project risk) that could have been avoided by investing time in fixing the underlying issues.

What you describe is not really technical debt but more a question of overall uniformity, which is IMHO not necessarily desirable. A good rule is "use the right tool for the job". It is perfectly fine to have e.g. a calculation engine in function style with a GUI in object-oriented code. Different patterns are appropriate for different problems. Trying to fit everything into a single pattern will not necessarily lead to better overall maintainability. Its about choosing the right pattern for each challenge, not the same pattern for every challenge.

You are correct that not all technical debt can be detected and flagged by automated tools. Automated tools are good for detecting the more trivial issues though, so they have value.

  • have you got any backup to show your definition of tech debt is correct?
    – Ewan
    Commented May 26, 2022 at 18:12
  • @Ewan: See for example here: wiki.c2.com/?TechnicalDebt
    – JacquesB
    Commented May 27, 2022 at 18:28
  • erm seems like a mishmash of various quotes
    – Ewan
    Commented May 27, 2022 at 18:46
  • @Even: Yes, it is a wiki created by Ward Cunningham who coined the term "technical debt". If you want a more clear definition you can go to Wikipedia: "technical debt [..] is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer."
    – JacquesB
    Commented May 28, 2022 at 8:39
  • I don't see how your examples follow clearly from either the wiki or the Wikipedia definition, or even your own tbh. eg. "bad variable names" arguably detectable with software, arguably makes maintenance harder, arguably "impedes development". It fits only in the broadest sense and you even argue against it a bit when you talk about uniformity not always being good. A tool with a rule will always be looking to impose uniformity on your variable naming example
    – Ewan
    Commented May 28, 2022 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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