> Code quality remains an abstract concept that fails to get traction at
the business level. Consequently, software companies keep trading
code quality for time-to-market and new features. The resulting
technical debt is estimated to waste up to 42% of developers’ time<p>Note: this paper was written by an employee of Codescene, the tool used in the paper to analyze code quality.<p>A codebase that is brittle - meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The solution to that is engineering managers that can make a persuasive case to non-technical people for why something needs to be done a different way, or failing that, will black box that entirely and add the needed maintenance to an existing business initiative. Put another way, play corporate politics like regular politics and tack what you need onto a bill that must pass. Showing an executive a report from code analysis tool is unlikely to work.<p>But as a founder and an active software engineer, far too often "technical debt" is used by programmers to advanced their personal preferences, which may not be aligned with the businesses in any way. A few highlights of things I've been told are technical debt in recent years: not using micro-services (when we had no need for the added complexity or scaling features), using promises instead of observables (in a non RX codebase), using a mono repo (again, zero business problems caused), using any number of 3rd party libraries (vs the developers desire to build from scratch), using Github instead of GitLab (or the reverse), etc...
The paper uses the term "technical debt" without defining it. From the context the term is used in its popular sense in which the primary source of debt is writing code poorly. Ward Cunningham, who coined the term, did not mean it in this way [1]. Wikipedia defines it as "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" [2] which is more aligned with Ward's intention. The problem with the current understanding of the technical debt metaphor is that it justifies poor code quality. Apparently it's like taking out a loan to make a sound investment.<p>1. <a href="https://youtu.be/pqeJFYwnkjE?t=196" rel="nofollow">https://youtu.be/pqeJFYwnkjE?t=196</a><p>2. <a href="https://en.wikipedia.org/wiki/Technical_debt" rel="nofollow">https://en.wikipedia.org/wiki/Technical_debt</a>
From the Abstract and Conclusion it seems this paper was driven to show a specific result instead of discovering something.
As the author wrote in the conclusion:<p>"This research was initiated to make code quality a business concern
by putting numbers on the impact of low-quality code. We chose
this line of research since code quality has been an abstract concept
that rarely gets adequate attention at the management level"<p>As a software manager, of course, I know Code Quality is important as it is at the core of maintaining a business software in the long run, especially when you have multiple teams and are hiring new engineers.<p>The thing is, IMO, even when you have code quality as a value in your team, you will have different opinions about which code quality standards are you going to have and some groups don't feel ok whatever the decision is.
I see that CodeScene's Code Health metric mostly looks at complexity and churn.<p>Here is a Ruby tool that gives you a similar report: <a href="https://github.com/chad/turbulence" rel="nofollow">https://github.com/chad/turbulence</a><p>And a Python one: <a href="https://github.com/danuker/lookout/tree/nohardcode" rel="nofollow">https://github.com/danuker/lookout/tree/nohardcode</a>