Balancing Technical Debt and Clean Code

Balancing Technical Debtand Clean Code

@dave1010Dave Hulbert

@wearebase@phpdorset

@dave1010Dave Hulbert

istockphoto.com

tensionnot.com

shutterstock.com

Good things

● Delivering fast● Clean code

Bad things

● Technical debt● Delivering slow

Code of Conduct

Carry out your professional responsibilities with due care and diligence in accordance with the Relevant Authority’s requirements whilst exercising your professional judgement at all times

How to develop quickly

Developers● Skilled, Passionate, Healthy,

Focused, Disciplined● Conferences, user groups, meet ups● Read books, blogs, code● Write code, Open Source

contributions

Projects● Good requirements● Good specifications● Fast feedback

How to develop quickly

(in the short term)

● Less testing● Less planning● Less communication● Don't improve tools /

processes● Overtime● Outsource

Technical Debt

Shipping code before it's ready

Shipping code without enough

architecture

Visible InvisibleGoodBad

thetruthaboutcars.com

Visible InvisibleGood FeaturesBad

uberhumor.com

flickr.com/dangelophoto1

Visible InvisibleGood FeaturesBad Defects

wikimedia.org

Visible InvisibleGood Features ArchitectureBad Defects

amazon.com

mirror.co.uk

Visible InvisibleGood Features ArchitectureBad Defects Technical debt

Technical Debt

thisismoney.co.uk

Good idea

● You think you'll be better off in the future

● The risk (interest) is manageable

Interest

● More user support needed● Manual tasks● Complete rewrite in future

Consequences● Less time on new features● Higher cost of new features● Harder to estimate new

features

bbc.co.uk

Complexity

Tests● Not comprehensive● Incorrect● Slow

We need to recognize that our job isn't about producing more code in less time, it's about creating software that is stable, performant, maintainable and understandable (to you or someone else, a few months or years down the road).

Matthew Gertner

Invest in architecture

Invest incode

TDD

● Run every bit of code that you write, ASAP

Write a test when you fix a bug

Domain-Driven Design

● Model the domain completely in classes that don't touch the UI, database or framework

How do you keep technical debt to a

minimum?

Refactoring

wikimedia.org

Refactoring● Restructuring without

changing behaviour● Makes it easier to read,

understand, test, change, add new features to

Refactoring● Inject dependencies● Eliminate dependencies● Create interfaces to type hint to● Extract functions● Rename● Reduce cyclomatic complexity● http://refactoring.com/catalog/

Estimating● Estimates for new features

need to include refactoring– (if you don't want to increase

technical debt)– Refactoring doesn't add perceived

value so it's hard to sell

Debt is expensive● Paying technical debt with

interest takes more time than continual refactoring

bonkersworld.net

Break the rules

● Help you deliver faster in the short term

● Long term strategy● Disposable prototype● Just don't need to write clean

code

Sprint vs MarathonSprint (example) Marathon (example)

Peripheral component (logs) Central component (DB)

Trivial (make a CSV) Complex (search algorithm)

Few consequences of bugs (game) Important (nuclear reactor)

Isolated (contact form) Reused (authentication)

Abandonable (migration script) Continued updates

One developer Big team

Time & money to pay technical debt later

Long term delivery

Investment in code is a balance

Thanks!

bitly.com/tech-debt-feedback

@dave1010

Dave Hulbert