7 Secrets of Maintainable Codebases • Adam Tornhill • GOTO 2016

This presentation was recorded at GOTO Stockholm 2016. #gotocon #gotosthlm

Adam Tornhill - Founder & CTO at Empear @adamtornhill2546

ABSTRACT
In this session you'll learn novel techniques that help you make sense of large codebases.
You'll learn to identify the code that really matters for your ability to maintain a system, how to prioritize improvements [...]

TIMECODES
0:00 Introduction
0:36 Let's Turn The Microscope
1:27 Behavioural Data
2:10 The challenges of Scale
4:59 Change Distribution of Files
6:04 Focus on the Code that Matters
12:34 Hotspots in Roslyn
15:37 Prioritize with Hotspots
19:16 Where's the Gorilla in your Code?
24:05 The Cost of Surprise
25:50 Physical Coupling
26:37 Logical Coupling
28:31 Analyzing Architectures
30:30 A Social View of Clojure
31:35 Excess Parallel Work?
32:09 Why Hotspots stay where they are
34:17 A Main Developer leaves Scala

Download slides and read the full abstract here:

RECOMMENDED BOOKS

#SoftwareArchitecture #SoftwareDevelopment #AdamTornhill

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[BeneWil_MgmtConsultantBeiBG]

7 (+1) Secrets:
#0 – Maintainable Code goes beyond Technology.
#1 – All code is equal (...but some code is more equal than others.)
#2 – Complexity isn't the problem (...at least not on its own.)
#3 – Your brain is not your friend.
#4 – Know your change patterns.
#5 – (Most) Organizational Problems are mistaken for technical issues.
#6 – Find your blind spots.
#7 – Make it fun.

[corsaro]

Did a really good job in keeping secret those 7 secrets

[JeremyAndersonBoise]

Fantastic talk, incredibly practical.

[aph]

To clarify implied: to support your decisions with data - test against your assumed hypotheses

[michaelharings]

"Fun is virtually a guarantee that things get done."--nice!

[jordanstewart]

What if code isn't changed because it has technical debt? If isn't changed because it has technical debt, if would invalidate the hypothesis Adam said, "you should focus on removing technical debt from code that is changed a lot".

Almost by definition, if code is being changed a lot is it easy to work with, and has low cognitive load on the developer. That could be because developers are familiar with that code, rather than the code itself is simple.

[jscancella]

Are there any automated tools that can help me do this myself?

[halfzbra]

Could you please explain what is teh reasoning behind the use of Fractal Figures diagram? Wouldn't a regular pie-chart do alright?

[ChrisAthanas]

9:46 it only took 56 victims before the police got a clue lol

[denisvorotyntsev]

I like how he compared software engineers and sex offenders

[aimafirm]

Can someone explain what the point of this talk is?

[logiciananimal]

Tragedy of the commons type situation on the code parts that have had many different people change it.

[edgeeffect]

Wasn't this old "GOTO" introduction SO much less annoying than the "boom bang zoom" of the newer intro.

[beavbeast]

3:02 Conway's Law give him credit!