2

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:

"MAINTAINABILITY ISSUE

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

https://www.sonarsource.com/why-us/code-quality/

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?

CLARIFICATION:

this tool will tell management that a line of code

this.myvariable

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.

  • 5
    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 May 22 '17 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 May 22 '17 at 21:17
  • Possible duplicate of How is technical debt best measured? What metric(s) are most useful? – gnat May 22 '17 at 21:29
  • @gnat I think Ewan's question is not addressed to find the definition of technical debt. More likely, if it should be defined by objective metrics. – Laiv May 22 '17 at 21:33
  • 4
    @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. – Derek Elkins May 23 '17 at 0:18
10

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.

techopedia.com

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 was 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 May 23 '17 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 May 23 '17 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 May 23 '17 at 12:19
  • 1
    "Does this bug you? I'm not touching you." What an excellent explanation of the feeling of technical debt for non-programmers! – DaveGauer May 23 '17 at 15:50
0

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 { 
   m,
   m.CyclomaticComplexity,
   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 Jun 18 '17 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. – James from CppDepend Team Jun 18 '17 at 9:42

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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