The business impact of code quality (2017)
&gt; 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 &quot;technical debt&quot; 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&#x27;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...