Prioritizing Technical Debt as If Time & Money Matters - Adam Tornhill




Software development at scale

Lehman’s “Laws” of Software Evolution

Lehman, M.M. (1980) Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 68, 1060-1076.

Continuing Change

Increasing Complexity

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

Increasing Complexity: consequences and impact

Impact on the Roadmap:

Impact on the team:

Impact on the users:

Quantifying Technical debt

Example: tried at a client on a 15 year old code-base. The tool reported 4,000 years technical debt. (It is unclear to me what this really means)

Conclusion: Quantifying technical debt is depressing, but it isn’t actionable as we cannot possibly invest that much time and money in the project.

Technical debt cannot be prioritized based on the code alone. The impact on the business is the interesting part. How much extra time is needed to develop a new feature because of the technical debt. This is something that cannot be measured from the existing code.

There is always a trade off between improving existing code and adding new features.

Behavior Code Analysis = code + people + context

The source code of Android: platform framework base

Code complexity - how hard it is for a human to understand the code - but it is the least interesting metric because it only matters when we have to deal with it.

What is more important is frequency of changes (commits) in an area of code.

Actually the really problematic code is the complex code that we have to change often.

Complexity explained: is “code quality” really a thing?

“The assumption that fundamentally different views of complexity can be characterized by a single number is counter to the fundamental concepts of measurement theory.”

“the most promising approach is to identify attributes of complexity and measure these separately” Software Measurement: A Necessary Scientific Basis

There is no such thing as “code complexity” (as a single number)

Healthy code: Beyond a single metric

Identify 20-25 different factors, depending on programming language.

Module level:

Function level:

Implementation level:

Finding bad code is easy. Finding which part to fix is hard.


Tech Debt and People

Mitigate off-boarding risks

That is when one of the contributor leaves.

There are 3 factors:

knowledge loss + relevance (hotspot) + impact (complexity)

There is more to Code Complexity than just the Code