The document discusses technical debt in software development. It defines technical debt as shortcuts taken due to ambitious deadlines and lack of resources that reduce code quality. This leads to increased costs of maintenance and changes over time. The document recommends avoiding technical debt by using modular architectures, test-driven development, and shared coding standards. It suggests either refactoring code incrementally over time or deliberately taking on small, documented amounts of debt for bursts of new features before cleaning up. Technical debt can also be accepted but the interest costs must be managed.

1. Using technical debt as an asset
Giving the market what it wants now without losing your pants later
Jesper Lindholt, Livatek – jlin@livatek.com

2. Introduction

3. Technical debt
• What is it and where is it from?
• How to avoid it
• Fixing it when you got it
• Using it as an asset (!)
source: www.defenselink.mil

4. Doing the right thing
Business
point-of-view
Doing the thing right
Tech
point-of-view
• What the market wants
• What we promised our users
• What we promised our investors
• What will bring fantastic value to our clients
• Right architecture
• Test coverage
• Modular
• Documentation

5. Where do things go wrong?
Too much
ambition
• Features
• Product
roll-outs
• Dead-lines
without
enough
resources
• Time
• Budget
• Skills
• Tools
leads to
technical
debt
• Corners cut
• Low quality
work
"Wet shorts" by philosophygeek

6. Increased
cost of change
Increased
software risk
Who wants to work with
stale and stinky code?
Increased
organizational risk
(incl. chief scientist)
Cowboy code that is
harder to maintain and
change
Lack of architecture
(beware creeping bug)
DEBT INTEREST %
Doing the
thing wrong

7. Technical debt => Cost of change
Cost of change
Time
Simple,
test-driven
designs
Rapid coding
without testing

8. Avoiding technical debt
Simple!
Do the Thing Right!

9. Levers and handles
Languages,
tools and
infrastructure
Process,
culture and
habits
Development
discipline
Software
architecture

10. Levers and handles
Languages,
tools and
infrastructure
Process,
culture and
habits
Development
discipline
Software
architecture
• Choosing right language
• Shared infrastructure
• Style checking tools
• Code conventions
• Demand unit-test coverage
• Strong definition of “Done”
• Service Oriented
Architecture
• Modularity
• Agree to having a process
• Team operating agreement
• Learning culture
• Test-driven development

12. BUT - you always do have a choice
Let your
customers down
Work harder Be deliberate
Focus your limited
resources in a way
that best prepares
you for the future
Work longer hours
Forget test coverage
Throw it all out the
window
Reduce internal quality
Reduce accountability
Say “no”

13. Be Deliberate

14. QUESTION TO SELF
Are we going to
be around longer
than short-term? YES

15. FUNDAMENTAL
Later – you will grow
- your product
- your team

16. That means that you will….
• decide on purpose where to cut
corners
• document corners cut in your task
management system
• use systems to support
communications and limit confusion
NOT, that you will
• have no time for architecture
• ignore the iron triangle of (function,
time, cost) and accept unrealistic
dead lines

17. We have it…..
Dealing with it

18. Dealing with technical debt
• Replace the whole thing –
debt repayment
• Incremental refactoring –
paying back in installments
• Live with it, pay the interest
And bear the opportunity cost
Gregory F. Maxwell <gmaxwell@gmail.com>

19. Technical Debt
As an asset

20. The exception to prove the rule
Cost of change
Time
Simple,
test-driven
designs
Rapid coding
without testing
INTERESTING!

21. Can we achieve this??
Cost of change
Time

22. Hacking it
• Throw all some rules out the window
• Do it in bursts – and then clean up
• Obvious advantage
• Leap forward for product functionality
• Less-obvious advantages
• Team bonding
• Team gets to find its limits Pay-back time!
Forget it, and you’ll be paying interest
- and interest of interest
Debt

23. My own pitch
Livatek
Team manager

24. Technical debt - summary
• Main source: when busy doing the right thing (needed in market) =>
not enough time/money to do the thing right
• Problems: cowboy code, lack of architecture, no test coverage
• Issues: cost of maintenance, cost of change, creeping bugs,
software risk, organizational risk
• Avoid with: modular SOA architecture, shared values in team,
unit-test coverage, test-driven development
• Accept it: only deliberately and when documenting
• Do not just: work harder and longer – but focus
• You have it: start all over, refactor module by module, or live with it
• As asset: code wildly for a week – and clean up for a week

25. Contact
Livatek GmbH
Hamburg
Germany
+49 40 60946277
de@livatek.com
Livatek A/S
Aarhus
Denmark
+45 7734 3090
dk@livatek.com
Jesper Lindholt, CEO
jlin@livatek.com
+380 50 410 8070
+45 3024 8500
@jlindholt / @livatek
linkedin.com/in/jesperlindholt