January 5, 2020

Prioritizing Technical Debt as if Time and Money Matters


Adam Tornhill, developer and author of some books, including Your Code as a Crime Scene


Nice presentation!!! Full of case-study and DATA! Data to corroborate your hypothesis about how code evolve. I’m still digesting some of the content of the video, but I already subcribed to the CodeScene service for some of my public github repositories.

Fantastic. I am analysing my Emacs dotfiles that I have been mantaining for a while. Pretty interesting and counter-intuitive results there about hotspot.

I would like to point out that he stated based on a research report that "old-code is much likely to have fewer bugs than new ones that implemented some similar solution" and that is fantastic counterpoint to Chad Fowler’s idea to code as a disposable artifact.

Fowler even mention that "you might think, that code that no one needs to touch is good code. But, are you sure?"


Lehman’s laws of software evolution:

  1. a system must be continually adapter or it becomes progressively less satisfactory

  2. as a system evolves, its complexity increases unless work is done to maintain or reduce it

What behaviour do we reinforce by quantifying technical debt?

Code findings problems that might add to complexity:

  1. low cohesion, many responsibilities

  2. overral complex methods, many conditionals

  3. deeply nested logic, if-statements, inside if-statements

  4. primitive obsession, missing a domain language

  5. excess function arguments, missing abstractions

Legacy Code:

  1. lacks in quality, and that

  2. we didn’t write ourselves

Social factors influence how we perceive a codebase

In microservice architectures, the most important aspects are not properties of the code but properties of the system


  1. Complexity metrics are not good for measure it. Therefore, pick whatever you want

  2. These metrics are not the most principle point here

  3. We should never go for a refactor so big

  4. Your Best Bug Fix is Time

  5. Old code is better than the new code

Tags: design ddd maintainability