A Crystal Ball to Prioritize Technical Debt • Adam Tornhill • GOTO 2017

This presentation was recorded at GOTO Berlin 2017

Adam Tornhill - Founder and CTO at Empear @adamtornhill2546

ABSTRACT
The technical debt metaphor has taken the software world with storm. No wonder, since software projects have their fair share of challenges. Most organizations find it hard to prioritize and repay their technical debt. The main reason is due to the scale of modern systems with million lines of code and multiple development teams; No one has a holistic overview. So what if we could mine the collective intelligence of [...]

TIMECODES
0:00 Introduction
0:31 Questioning Technical Debt
5:53 Collective Intelligence Uncover Evolutionary Patterns In A System
11:46 Case Study: The .NET Core Runtime
13:49 Hotspots X-Ray
14:55 Normalization of Deviance
19:44 Hotspots Summary
21:39 Specify Your Logical Components
24:32 Temporal Coupling
29:56 The Microservices Shotgun Surgery Pattern
33:20 Process Loss
36:14 Measure Team Coordination The Diffusion of Responsibility
38:16 Measuring Conway's Law
39:28 The Perils of Feature Teams

Download slides and read the full abstract here:

RECOMMENDED BOOKS

#TechnicalDebt #TechDebt #AdamTornhill

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[Achrononmaster]

Good question & answer around @45:00. I don't think a strong case has been made for software alignment within a large software organization, but organizational alignment yes (cooperation on revenue and knowledge sharing and scheduling). The more coupled code becomes the harder to maintain, so the Unix philosophy seems to always apply to software --- the more modular the better, and let different components communicate via clear interfaces, with interfaces being the exact opposite, i.e., highly public and shared. Seems to me the only time you do not want modularity and independnet teams (except for their interfaces) is when the design just cannot be modularized, and is like a vast neural network type of architecture. In that latter case the architecture better be highly robust in the anti-fragile sense (corruption of any part has insignificant effects) and should have holographic aspects. Very few conventional and typical current tech projects will have that sort of anti-fragility, so very few projects will need coordinated aligned teams. Your business alignments will tend to all be external focus, client deadlines, shared monetary costs and revenues, etc, not software alignments. The more you keep software alignments strictly to interfaces the better. Then you should also treat code re-use as a separate system-wide effort, so that teams regularly come into contact to share ideas and broad solutions to common problems, not as software module entanglements but as shared knowledge coordination. This is natural to me, the way your body and mind are modular, you share the output of your bodily work and mind with others, you do not share and align the individual parts of your mind and body.

[AnitShrestha]

great talk. look forward to more. thanks.

[JaysonSunshine]

Adam has a lot of good habits for speaking. :)

[Achrononmaster]

I'd suggest not just commit hotspots, but bug report/fix hotspots should be nearly as important. Trouble is patches are not always reported as bug fixes, but if you have a large enough code base you might still get fair statistics just by looking for the word "bug" or "fix" in git commit comments, and make an organizational habit out of git commenting bug fixes as such.

[gamehelp]

Almost all of this already known in academia. Presentation has no references to prior work. He presents as if it is all new discovery and his discovery. Looks like a marketing talk for his consultancy work.