Technical Debt, Legacy Code, Legacy Systems … whatever you want to call it, is a common problem. It needs to be surfaced to the people whose lives it affects the most: the users; stakeholders; purse holders; and any other recipients of a poor experience. Through awareness of these issues, these stakeholders can understand and endorse a need to change. Human made systems which once met a need and now cannot change to meet our emerging needs become like a tail wagging a dog. Who is in control here? The system? We humans created these systems - we ought to be able to change them. Note: this doesn’t just apply to technology. In this session, Sean introduces a simple yet effective way to identify and prioritise what to work on, in a way which makes most sense for stakeholders and custodians. - Given by Sean Moir for Ox:Agile Conference 2019.

1. Sean Moir

2. §18Years Coding, Lecturing, Leading, Mentoring, Managing
– “old school”
§Agile since 2010
§Freelance Coach since 2013
§ Sectors
§ Telecoms; Charity; Insurance; Pharma; Public Sector; Fenestration
§Founder of Swindon Agile Practitioners (estd. 2014)
§MeetUp and Conference Speaker

3. Be able to use a
technique which
suggests a route
to address
technical debt
The technique is:
• Collaborative
• Transparent
• Objective
• Quick
• Easy

4. §Respond to the rapidly changing
competitive landscape
§Provide stable, reliable, and
secure service to the customer
The DevOps Handbook – Gene Kim, Jez Humble et al

5. Some problems with code
are like financial debt.
It’s OK to borrow against
the future, as long as you
pay it off
https://www.techopedia.com/definition/27913/technical-debt

6. https://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html

7. “To me, legacy code is simply code
without tests.”
“Code without tests is bad code. It doesn’t matter how well
written it is; it doesn’t matter how pretty or object-oriented
or well encapsulated it is.With tests, we can change the
behaviour of our code quickly and verifiably.Without them,
we really don’t know if our code is getting better or worse.”
Working Effectively With Legacy Code – Michael Feathers

8. §Software was invented to overcome the limitations of
hardware.
§Software that cannot be changed is not software
§Software has two values
§ The functionality it provides
§ The ability to change
§ Without both of these qualities, your software is hardware
§ Without the second quality, you cannot maintain the first ..
www.cleancoder.com – Robert “Uncle Bob” Martin

9. Always code as if the person
who ends up maintaining
your code is a violent
psychopath who knows
where you live
John F.Woods – https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4lXw/oITtSkZOtoUJ

10. §Complex, undocumented and
fragile system
§Guilt and over promising
§Everyone gets a little busier, work
takes a little longer, …
The DevOps Handbook – Gene Kim, Jez Humble et al

11. §Users are afraid to ask for changes
After what happened last time…
§Engineers are wary of making changes
After what happened last time…

13. This is pretty miserable
We know this is wrong
§Users secretly want changes
§Engineers wish they could make
changes safely

14. §For your environment, identify a broad coalition
§Users
§Stakeholders
§Product Owners
§Project Managers
§Developers
§Testers
§Operations
§…

15. §Invite the Coalition to a meeting about Stability of
the system in question
… Or whatever you think means that they will show up!

16. Goal:To collectively decide what
to work on so that we regain
control of our system
§Create a Backlog
§Process the Backlog
§Review findings
§Generate Actions

17. Identify areas or components* of the system
which represent risk to the organisation **
§Each attendee selects 2 or 3 system Components
which they are most concerned about, writes one
Component per post-it, and presents back to
group
§Identify where the same part of the system has
been identified - group these together
** Use terms that all attendees understand
* Component is not an Engineers’ term here. It means a logical part of a system

19. §When everyone has presented, allow the group to
propose changes, to check
§Nothing important was missed
§Components could be split or merged
§Score each Component based on the number of
post-its
§Place post-its in a backlog column, ordered by the
number of post-its – high to low

20. Component Count
A 5
B 5
C 3
D 3
E 2
F 1
G 1
H 1
I 1

21. We’ll use 3 Dimensions of Risk for each component *
§Impact of failure
§ If things go wrong here, how bad could it be?
§Likelihood of change
§ What is the appetite for changes which affect this area of the
system?
§Difficulty of change
§ How hard is it to make safe changes in this area?
* AKA ‘Risk Cube’

22. Scoring system
§Binary numbers, 0 to 16 *
§0, 1, 2, 4, 8, 16
§0 – non-existent
§16 – extremely high
* Could use modified Fibonacci sequence if preferred

23. For each scoring category, score each component *
§ Start with Business Impact of failure
§ May be skewed towards Business representatives, but try to get input from everyone
§ Likelihood of Change
§ Encourage people to be creative about reasons to change. ”Why might we need to change this
area?”
§ Difficulty of Change
§ Engineers and Testers will have views on this. There are other effects of change they may not be
aware of.
Encourage discussion
§ Rule: No biting, scratching or pulling hair
* Can accept either a consensus or an average

24. Component Count Likelihood Impact Difficulty
A 5 2 16 8
B 5 1 16 4
C 3 16 16 4
D 3 16 16 4
E 2 4 8 16
F 1
G 1
H 1
I 1

25. Verify the relative scoring in each Category *
“Is Component X really twice as likely to change than ComponentY?”
“We’re saying that Component X is very harmful if it goes wrong?”
“Component X is about as difficult as ComponentY to change?”
* Find the extremes then verify relative scores

26. Calculate a score for each component
Business Impact of Failure + Likelihood of Change
Difficulty of Change

27. Component Count Likelihood Impact Difficulty Final Score
A 5 2 16 8 18/8 = 2 1/4
B 5 1 16 4 17/4 = 4 1/4
C 3 16 16 4 32/4 = 8
D 3 16 16 4 32/4 = 8
E 2 4 8 16 12/16 = 3/4
F 1
G 1
H 1
I 1

28. You have collectively arrived at an objective strong suggestion of
which problem parts of the system should be worked on.
The coalition is aware of the issues within the system and has a
potential route to a solution.
Note
§ The values are indicative guides.There may be very good reason to
start elsewhere
§ System Dependencies
§ Lack of skills in the specific area

29. Collectively agree how and when the work can
begin
This work is first class work and is not subservient to
new feature requests. It has a very valid reason to be
at or near the top of the Backlog
Workers who will perform this work need to
understand the context – ideally they will have been
present in the initial session

32. §Refactoring
§xDD frameworks
§Strangler pattern *
§Care and attention
* Rotten code is superseded and bypassed. No code is harmed in this process

33. “A seam is a place where you
can alter the behaviour in
your program without editing
in that place”
Working Effectively With Legacy Code – Michael Feathers

34. §Find Seams
§Change behaviour within Test
environment
§Break dependencies
§Create Tests
§Refactor
§Rinse and Repeat

35. § Clutter: Clutter is anything in the code that does not add value
§ Format your code
§ Delete comments; dead code; unnecessary code
§ Complexity:
§ Bad names; Magic Numbers
§ Long functions/methods
§ Deep conditionals (if/for/while/switch)
§ Improper variable scoping
§ Multiple responsibilities
§ Obscure code blocks
§ Cleverness: If it is simple and elegant, you wouldn’t describe it as ‘clever’
§ Cryptic code
§ Abbreviated code
§ Hijacking a method (changing it’s intent for your own purpose)
https://www.youtube.com/watch?v=aWiwDdx_rdo

36. Duplication
Duplication
Duplication
https://www.youtube.com/watch?v=aWiwDdx_rdo

37. Horizontal axes
characteristics are
initially
environmental
They cannot be
changed in the
short term
Business Impact of Failure
Likelihood of Change
Difficulty of Change
X X

38. Refactoring the
system helps
make it easier and
safer to change
Business Impact of Failure
Likelihood of Change
Difficulty of Change
X X
X X

39. Easier and safer
changes reduce
risk of failure in
the medium term
The Business
Impact of Failure
remains the same
but is less likelyRisk of Change
Difficulty of Change
X XX X

40. Easier and safer
changes increase
the appetite for
change in the
medium term
Likelihood of Change
Difficulty of Change
X X X X

41. Are you
comfortable you
could you use this
technique?
Is the technique:
• Collaborative?
• Transparent?
• Objective?
• Quick?
• Easy?

42. sean.moir@facilligent.com
http://bit.ly/HandleTechDebt
Please provide me feedback so that I know where I can improve