Code Red: The Business Impact of Code Quality • Adam Tornhill • GOTO 2022

This presentation was recorded at GOTO Copenhagen 2022. #GOTOcon #GOTOcph

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

RESOURCES

Adam

ABSTRACT
Code quality is an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for new features. The resulting technical debt is estimated to waste up to 42% of developers' time, causing stress and uncertainty, as well as making our job less enjoyable than it should be. Without clear and quantifiable benefits, it's hard to build a business case for code quality.

In this talk, Adam takes on the challenge by tuning the code analysis microscope towards a business outcome. We do that by combining novel code quality metrics with analyses of how the engineering organization works with the code. We then take those metrics a step further by connecting them to values like time-to-market, customer satisfaction, and road-map risks. This makes it possible to a) prioritize the parts of your system that benefit the most from improvements, b) communicate quality trade-offs in terms of actual costs, and c) identify high-risk parts of the application so that we can focus our efforts on the areas that need them the most. All recommendations are supported by data and brand new real-world research. This is a perspective on software development that will change how you view code. Promise. [...]

TIMECODES
00:00 Intro
00:25 What is technical debt?
05:11 Visualize technical debt & code complexity
15:19 Quantify the business impact of code quality
19:45 Does code quality matter?
28:37 Prioritize large amounts of technical debt
34:54 Resources
35:36 Outro

Download slides and read the full abstract here:

RECOMMENDED BOOKS

#CodeScene #CodeAsACrimeScene #AdamTornhill #TechnicalDebt #Legacy #LegacyCode #DeveloperProductivity #CodeComplexity #Complexity #CodeSmells #RedCode #GreenCode #CodeQuality

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[ericlegoubin]

Synthesis

* The impact on developer productivity caused by technical debt is estimated at 25% to 40%.
* Code can be classified into 3 categories by an algorithm: green - easy to maintain, orange - requires some attention -, red - difficult terrain.
* When we compare the work on green code and red code, we see that the work time is doubled, the uncertainty on the deadlines is multiplied by 9 and the number of defects is multiplied by 15 between green code. This impacts the ability of IT to serve the business strategy.
* As DORA pointed out, quality and speed can go hand in hand.
* Remediation of debt can be focused on frequently changing red code, also known as hot spots, to maximize the return on repair
* The impact of technical debt on employees is very important.
* The psychological effect, the hyperbolic discounting, explains why we privilege the degradation of the code in the short term compared to the maintainability of the code in the long term.

My opinion

* The quality of the code is not taken into account in our financial models because we do not measure the productivity of the developer and the time to completion (not to be confused with the date of release)
* This presentation has the great merit of showing the link between the technical debt and the business. Thank you!
* We expect the collaborators to compensate the technical debt. This is part of the maintenance package. In reality, we have dissatisfied employees. I'm in tune with the impact of debt on employees.

[brnto]

This is great! I wish organisations would apply these metrics to their business processes and product options too… I’m sure there is a parallel there

[TheVampWillow]

Now I also know about; Hyperbolic discounting and Conway's Second Law!

[gdargdar]

Excellent outlook. But I think the hotspots part is an oversimplification. Even if hotspots themselves aren't that much, in order to refactor them, sometimes you have to also refactor a lot of the stable code. I too think prioritizing hotpots is still a way to go, but don't expect they will be enough.

[xCAFEFD]

I don't know if it was intentional but the early portion of the talk seems to imply it's the developers drive to new features that's the problem.
I don't agree with that at all. Personally it's management or users themselves that put on this pressure. In an environment without those two, like hobby projects, you either just do quick features because you know you don't care about maintainability, it's just a quick script or whatever, only you will use it etc. Technically technical debt, but it's a concious decision to not maintain. Or you get to indulge in writing the kind of code you dreamed of. You make it convenient, maybe even play with esoteric language features and new langauges that you don't get to play with on the job. It's a completely different world where you don't really bring on technical debt. It's got nothing to do with how pleasing it is to bring features to users.

But as a general point about how people asses benefits it makes perfect sense. The benefits of new features is more obvious than paying technical debt interest.

[Cygx]

Hyperbolic discounting = kicking your future self in the foot

[xiaokourou]

Debt - It's pronounced det. Dont like correcting non native speakers on their English but come on, it's the whole topic and he says it 50 times