Technical debt and code smells

In short: Technical debt is shortcuts in code that save time now but later cost “interest” in the form of extra effort; code smells are warning signs of it.

In more detail: The term comes from Ward Cunningham. Whoever picks a messy solution under time pressure takes out a loan: progress is faster, but every further change gets more laborious until the debt is repaid (by cleaning up). Not every debt is bad as long as it is taken on deliberately and repayment is planned.

In Depth

Kinds

• Deliberate and prudent: “We ship now with a simple solution and expand it after launch.”
• Inadvertent: you only realise later that the design was poor.
• Reckless: “We have no time for tests.” Besides code, missing tests, outdated libraries, missing documentation and manual procedures also count.

Typical code smells

• Long method / large class: does too much.
• Duplicated code: the same logic in several places.
• Magic numbers: unexplained constants such as if (status == 7).
• Long parameter lists.
• Feature envy: a method is more interested in foreign data than in its own class.
• Dead parts: unused code and old comments.
• Nested conditions over many levels.

Dealing with it

Make debt visible (list in the ticket system, TODO marker with ticket number). Plan part of the time regularly for cleaning up instead of hoping for one big rework. By the boy scout rule you leave each piece of code a little cleaner than you found it. Tools such as static analysis (SonarQube, ESLint) show smells and complexity.

Caution

Not everything ugly is debt worth paying off: code that runs stably and is never touched costs little interest. Conversely, you should pay down debt first in areas that are changed often.

See also: Refactoring, Clean code, Spaghetti code, Code review