Prioritizing Technical Debt as If Time & Money Matters • Adam Tornhill • GOTO 2022

This presentation was recorded at GOTO Amsterdam 2022. #GOTOcon #gotoams

Adam Tornhill - Founder & CTO at CodeScene & Author of Several Books Including "Your Code as a Crime Scene" @codescene-softwareengineer6553 @adamtornhill2546

ABSTRACT
Many codebases contain code that is overly complicated, hard to understand and hence expensive to change and evolve. Prioritizing technical debt is a hard problem as modern systems might have millions of lines of code and multiple development teams — no one has a holistic overview. In addition, there's always a trade-off between improving existing code versus adding new features so we need to use our time wisely.

What if we could mine the collective intelligence of all contributing programmers and start making decisions based on information from how the organization actually works with the code?

In this presentation, you'll see how easily obtained version-control data lets you uncover the behavior and patterns of the development organization. This language-neutral approach lets you prioritize the parts of your system that benefit the most from improvements so that you can balance short- and long-term goals guided by data. The specific examples are from real-world codebases like Android, the Linux Kernel, .Net Core Runtime and more.
This new perspective on software development will change how you view code.

In this talk, you'll learn:
• To prioritize technical debt in large-scale systems
• To balance the trade-off between improving existing code versus adding new features
• To measure long time trends in technical debt [...]

TIMECODES
00:00 Intro
00:33 Lehman's "laws" of software evolution
03:17 Technical debt
07:39 Case study: Prioritizing technical debt
10:25 Can we measure "code complexity"?
19:27 Technical debt & people
22:33 Case study: How quickly can you turn your current codebase into legacy code?
27:48 Resources

Download slides and read the full abstract here:

RECOMMENDED BOOKS

#Legacy #LegacyCode #DeveloperProductivity #CodeComplexity #Complexity #Teams #TechnicalDebt #AdamTornhill

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[josda]

This is why code really is hard to maintain... people leaving, taking their knowledge with them, but also even your own code can become "legacy" because you improve over time, but you wrote that console job that runs monthly a decade ago, and now we have to make changes because of govt regulation. So no it's not just churn that's a factor, but knowledge changes themselves. So keeping code as clean as possible all the time is an actual goal. Except for those that like to go fast without realizing their actions have consequences.
Awesome talk, i love this guy.

[krccmsitp]

Definitely one of the best talks I've seen the last year.

[nekony]

It could be also in reverse. A large file with frequent changes means that people managed to do them relatively easily. So, this file might be not that bad. But when you open some rarely touched file to slightly modify it for your 2 story points task and after 10 minutes you start asking yourself about your life... 😄

[ncuxap]

This encapsulates the programming experience so well. Software engineering is all about solving these issues. It doesn't matter that much what exactly is the product, the problems are the same.

[amodo]

The long tail of unchanged code may harbor exactly those bad (or outdated) abstractions and assumptions that make working with the high-frequency code so painful and inefficient...

[argfasdfgadfgasdfgsdfgsdfg]

These metrics don't take into account that some files might have a low code change frequency BECAUSE they have so much technical debt. If nobody understands a specific file, nobody will dare to change it.

[RoamingAdhocrat]

at my employer we have a weekly meeting to discuss bugs and minor feature requests raised from the service desk. inexplicably this work is labelled "tech debt"

[seetlive]

Valuable lecture, it is a big challenge to write quality code.
I've been refactoring a code base the full today, making it more resilient for future development. While I was doing so I was thinking about what could be done better to reduce refactoring in the future, writing code that lives longer.

[Syntax]

This is fantastic! What a wonderful breakdown of "what matters" in tech. Measuring, ordering and actioning such a complex topic in such a visual way can only come from a genius mind at work. Nobel prize vote from me!

[blarghblargh]

Suitability of software doesn't strictly decrease over time. Needs can evolve, but they don't always. I would argue that most software is built under the assumption of a growth economics model, and requires the software to continually adapt in order to meet the revenue model of the company selling the software, rather than the suitability of the software to existing customers. This is something that can be pigeon-holed into the first "'law" in this talk, but the subtleties of such distinctions is extremely important if we are interested in seeking truth (the "root cause" as described in the talk). It can strongly impact the *types* of modifications that changing requirements entail, as well as the volume of changes.
If you insist on focusing your lens to only include the code side of things, then you can't optimize the experience for existing customers. This is a reason that it's best not to bury your head as a developer.

[nickeshchauhan]

I disagree with the metric of measuring employees by code contribution. While it may be true that losing a high contributor is bad, it's not true that losing a low contributor is acceptable - senior developers tend to review code or plan architectures, which wouldn't show up in this metric.

He also mentions the size of functions being a problem and implies that factoring is a good thing. However this assumes that the factored code is relevant to other parts o the codebase, and actually increases code complexity because you've turned linear code into potentially non-linear code.

[petabrain]

Offensive implementations are usually left alone because the rest of the code depend on these. I'd argue that frequency of change of offensive implementations isn't what we're after, I think the scale should be measured by uses of offensive code -- i.e. how likely it is to impact you when you're writing new code or changing existing code.

[xarz]

Sometimes we don't touch code that works because we are just too scared to break it or we just don't have enough time and resources to do so. So we don't change it, even at cost of dropping useful features we'd like to have. This is the worst type of technical debt because it totally limits your innovation and business opportunities, and this can't be identified observing the git history

[afnanahmad]

WOW !!! Wonderful explanation. Each and every word is so clear. Simply awesome !

[WillGilpin]

Great talk. I hate to be that guy, but I am that guy... the B in debt is silent. It's pronounced DETT. The B was added by some pretentious brits a couple of hundred years ago to prove they knew Latin, but didn't change pronounciation. Same for plumber (PLUMMER), doubt (DOUT) etc.

[JeffHanke]

Thanks for the talk! I really like the idea of mining version control for data and combining that with other metrics to inform decisions on how to prioritize dealing with technical debt.

[MartinChaov-lpgx]

Legacy is a gift from the past for a better future!
- No Developer Ever

[BrennanYoung]

There's a real bona fide mathematical law which rarely gets the attention it deserves. It's called "the law of requisite variety", formulated by cybernetics pioneer W. Ross Ashby when computer science barely existed.

Lehman's pseudo-laws are special cases of this true mathematical law. Even using the base 2 logarithm to calculate the requisite number of bits for representing a known number of states is a special case of this law.

So what is "the law of requisite variety"? It may be expressed in many ways, because it pertains to any communicative domain, but here:
A system (e.g. a piece of software, or a team) which should cope/thrive in/handle an environment (e.g. a market or a user base) must contain a model of *all* the pertinent variations in that environment, but no more.

If there is too little variety in the model, the system will fail to account for some states/conditions (-> unhappy users/customers). If there is too much variety (e.g. technical debt, or "greedy" modelling) the system becomes unwieldy and inefficient (-> unhappy users/customers).

"MVP" is agile jargon for a system whose complexity closely matches the target (sprint goal) environment - a system with "requisite variety".

[dananskidolf]

Seeing the hotspots from the source control history is a neat idea and it would pick up some of my least favourite source files immediately. But in the interest of prioritisation of technical debt, you often want to focus on code improvements to prepare for a particular upcoming feature, which means identifying something _before_ it becomes a hotspot, so that the new feature built on top isn't slowed down by the pre-existing code problems.

[oShwavyo]

I just wanna say that the earliest writing systems are over 5000 years old, and that hieroglyphs are not the first known writing system. My man’s did cuneiform dirty and I won’t stand for it.