On: The business impact of code quality (2017)

[reedlaw]

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.

1. https://youtu.be/pqeJFYwnkjE?t=196

2. https://en.wikipedia.org/wiki/Technical_debt

[andsoitis → reedlaw]

> "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.

Precisely. A useful way to think of technical debt is that it should be a tool that is intentionally used to navigate the tension between cost now vs. later, for some benefit (usually quicker delivery).

If code is poorly written inadvertently (e.g. lack of experience, poor programming skills, carelessness, etc.) that is a different kind of burden on those working in the codebase.

[Domenic_S → reedlaw]

They define it in the second sentence as "trading code quality for time-to-market and new features". Section 2 defines code quality ("This section defines the metrics for code quality"), which is helpfully (/s) measured by the tool they sell.

[reedlaw → Domenic_S]

Quite right. Thus they implicitly equate poor quality code with technical debt. This makes the metaphor unsuited to a proper aversion to poor quality code. If it's simply debt it can be paid off later with a small amount of interest. Such a conclusion is contrary to the one the paper is trying to put forth.

[rileymat2 → Domenic_S]

Assuming that they ran the experiment in earnest, doesn't that strongly indicate that whatever code quality metrics in their product target are a pretty good signal? (Until people target those metrics)