Tech debt will kill us

Preview:

Citation preview

Tech debt will kill us

Managing technical debt at enterprise scale with Sonarqube

by Julian Warszawski

What is tech debt

• Abstract term

• Lots of definitions

• Not useful

Which terms associate with tech debt?

pressure

long term goals

short term goals

clean code

hack

accidental design

automation

workaround

What is tech debt

forget code quality

forget bug count

forget engineers morale

Delivery Speed ~ 1/Tech Debt

Only thing to know about effects of tech debt

Why will it kill us

It takes 2 months for anyone to ramp

up on this codebase

It used to take 5 people to keep

up. Now it is 25.

95% of the team is fixing

bugs

It will be easier to rewrite this

component than extend it.

Why delivery speed drops?

• Designing from scratch is super fast

• After first sprint you don’t design from scratch

• Existing complexity slows down further design

• Complexity ALWAYS grows

• There is domain complexity and accidental complexity

• You CAN control accidental complexity

What can we do

src: sixsigmadaily.com

Define

Accidental complexity

Untested code

Tangled packagesLack of cohesion

Copy-paste code

not following best practices

Measure

• Java: checkstyle, pmd, jacoco, pitest, …

• Python: Pylint

• C++: cppcheck, gcov, custom plugins.

• Other languages: C#, SQL, PHP, Flex, XML, Groovy and others

Analyze

Improve

Control

compile

unit testing

integration testing

quality gate

functional testing

ship it

Sonarqube

sonar dashboard sonar runner

source repo

CI Servercommit pull

run

publish

DEMO

demo

What’s in it for DEV

Less tech debt

More time for features

better software

Ambitious DEVMy code will

be PROLazy DEVLess possibility for something to break. No

STRESS

What’s in it for PM

Less tech debt

More time for features

predictability

Agile PMWe can deliver

fasterWaterfall PMFinally

everything goes according

to PLAN

What’s in it for CEO

Less tech debt

More time for features

improved delivery

capabilities

Fresh CEOI don’t have to worry about

BAU, can focus on strategy

Retiring CEOClients are

happy, stocks are up

Doubts

• This does not present REAL design debt. It hides the real design debt.

• Yet another step in our build pipeline. Can we afford it?

• Focus will be shifted from delivering products to improving sonar metrics.

This is not REAL design debt

• Accidental complexity is real design debt

• Untested code is real design debt

• Accurate correlates of design problems

• Degradation: correlate of process problems

• By observing symptoms, you can be proactive

Another step in the pipeline

• No, if set up correctly

• Quality gates – warnings and fails

• Does not have to monitor every commit (nightly checks)

• Do not block the pipeline, allow fast reverts

• Focus on prevention

Focus shifted to improving metrics

• These metrics are symptoms, not the essence

• You don’t fix tech debt by just fixing compiler warnings, test coverage or static violations

• Do not compete for grades

• DO NOT MANDATE THRESHOLDS!!!

DO NOT MANDATE THRESHOLDS

• People should work 8 hours a day

• Do you have alerts if they leave job too early?

• Thresholds promote ignorance

• E. g. it is more important to write good tests than achieving the coverage goal

• Boy scout rule: Leave the code simpler and cleaner than it was when you saw it.

Who benefits more

Game DevelopmentFire and forgetSales POCDelivering in 1 month more critical than future-proofing

Codebase is representing a core productProduct addresses long term strategyProduct will be extended for years

little value lots of value

QUESTIONS

any

Recommended