The document discusses different types of software debt including technical, quality, configuration management, design, and platform experience debt, emphasizing the long-term consequences of ignoring these issues. It explores concepts like refactoring and test-driven development (TDD) as strategies to manage and reduce software debt. Additionally, it highlights the importance of maintaining quality standards and effective team structures to address software challenges efficiently.

1. Managing Software Debt in Practice
“What he needs is some way to pay back. Not some way to borrow more.”
- Will Rogers
Chris Sterling
VP of Engineering
AgileEVM Inc.
Web: www.AgileEVM.com
Email: chris@agileevm.com
Blog: www.GettingAgile.com
Follow Me on Twitter: @csterwa
Hash Tag for Presentation: #swdebt
1

2. Chris Sterling – Sterling Barton, LLC
Partner, Sterling Barton, LLC
Author of Book “Managing Software
Debt: Building for Inevitable
Change”
Consults on software technology,
Agile technical practices, Scrum,
and effective management
techniques
Email: chris@sterlingbarton.com
Web: http://www.agileevm.com
Certified Scrum Trainer Blog: http://www.gettingagile.com
Follow me on Twitter: @csterwa
Innovation Games® Trained
Facilitator
Open Source Developer
© 2009-2011, 2
2

3. Types of Software Debt
Technical Debt: These are the activities that a team or team members
choose not to do well now and will impede future development if left
undone.
Quality Debt: There is a diminishing ability to verify the functional and
technical quality of software.
Configuration Management Debt: Integration and release management
become more risky, complex, and error-prone.
Design Debt: The cost of adding features is increasing toward the point
where it is more than the cost of writing from scratch.
Platform Experience Debt: The availability of people to work on software
changes is becoming limited or cost-prohibitive.
© 2009-2010, 3
3

4. Technical Debt
“Lowering quality lengthens development time.” - From wiki page on “First Law
of Programming” (c2.com)
4
4

5. Patterns of Technical Debt
Duplication
Schedule Pressure
Get it “right” the
first time mentality
© 2009-2010, 5
5

6. Aspects of the software’s design that teams agree to
should be automated, if possible, and break the build
when they are not adhered to.
© 2009-2010, 6
6

7. Keep DRY (Don’t Repeat Yourself)
© 2009-2010, 7
7

8. No matter what, the cost of addressing
technical debt increases with time.
© 2009-2010, 8
8

9. Principles of Executable Design
The way we design can always be improved.
We’ll get it “right” the third time.
We will not get it “right” the first time.
Design and construct for change rather than longevity.
Lower the threshold of pain.
If we are not enhancing the design then
we are just writing a bunch of tests.
© 2009-2010, 9
9

10. Merciless Refactoring
Refactoring: a disciplined technique for restructuring
an existing body of code, altering its internal
structure without changing its external behavior.*
Merciless: having or showing no [mercy - showing
great kindness toward the distressed]
Relieve your distressed code through kindness and
disciplined restructuring
* From http://www.refactoring.com/
© 2009-2010, 10
10

11. Where to Start Refactoring?
Does this change directly affect feature I am working
on?
Would change add clarity for feature implementation?
Will change add automated tests where there are
none?
If “yes” to any question above, ask following question to
decide if you should work on it now:
At first glance, does refactoring look like a large
endeavor involving significant portions of the
software’s components?
© 2009-2010, 11
11

12. When to Stop Refactoring?
Am I refactoring code not directly affected by feature?
Is other code directly affected by feature I am working on that has
not been refactoring sufficiently?
If refactoring is exploding feature estimate given to Customer
then I should bring it up to Team to decide how we should
progress
If Team decides that refactoring can be absorbed into current
iteration without affecting delivery on our commitments then
continue refactor
If refactoring affects commitments then bring it to Customer for
discussion how to proceed
© 2009-2010, 12
12

13. Automate Testing to Support Refactoring
Refactoring cannot be done effectively without
automated tests surrounding code
Start by creating automated test which fails
If difficult to create at unit level look at
automated acceptance tests from functional
perspective
Over time look for ways to create automated unit
tests
© 2009-2010, 13
13

14. TDD - Basic “Flow”
© 2009-2010, 14
14

15. TDD - Basic “Flow”
Write
Failing
Test
© 2009-2010, 14
14

16. TDD - Basic “Flow”
Write
Failing
Test
Make
Test
Pass
© 2009-2010, 14
14

17. TDD - Basic “Flow”
Write
Failing
Test
Refactor
to
Make
Test
Acceptable
Design Pass
© 2009-2010, 14
14

18. TDD - Basic “Flow”
Write
Failing
Test
Refactor
to
Make
Test
Acceptable
Design Pass
© 2009-2010, 14
14

19. Ji:er
–
Example
TDD
Session
• Fake
micro-­‐blogging
tool
named
“Ji4er”
is
made
by
Sea4le-­‐based
fic::ous
company
that
focuses
on
enabling
coffee
injected
folks
to
write
short
messages
and
have
common
online
messaging
shorthand
expanded
for
easy
reading.
The
user
story
we
are
working
on
is:
So
it
is
easier
to
read
their
kid’s
messages,
Mothers
want
to
automaFcally
expand
common
shorthand
notaFon
• The
acceptance
criteria
for
this
user
story
are:
– LOL,
AFAIK,
and
TTYL
are
expandable
– Expand
lower
and
upper
case
versions
of
shorthand
15
Copyright © 2010 Sterling Barton. All rights reserved.
15

20. Expand
LOL
to
“laughing
out
loud”
public class WhenMotherWantsToExpandMessagesThatContainShorthandTest {
@Test
public void shouldExpandLOLToLaughingOutLoud() {
JitterSession session = mock(JitterSession.class);
when(session.getNextMessage()).thenReturn("Expand LOL please");
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(),
equalTo("Expand laughing out loud please"));
}
}
public class MessageExpander {
public String getNextMessage() {
String msg = session.getNextMessage();
return msg.replaceAll("LOL", "laughing out loud");
}
16
Copyright © 2010 Sterling Barton. All rights reserved.
16

21. But
wait…what
if…?
• What
if
LOL
is
wri:en
in
lower
case?
• What
if
it
is
wri:en
as
“Lol”?
Should
it
be
expanded?
• What
if
some
variaFon
of
LOL
is
inside
a
word?
• What
if
characters
surrounding
LOL
are
symbols,
not
le:ers?
Write
these
down
as
upcoming
programmer
tests
as
comments
so
I
don’t
forget
them.
// shouldExpandLOLIfLowerCase
// shouldNotExpandLOLIfMixedCase
// shouldNotExpandLOLIfInsideWord
// shouldExpandIfSurroundingCharactersAreNotLetters
17
Copyright © 2010 Sterling Barton. All rights reserved.
17

22. Expand
LOL
If
Lower
Case
@Test
public void shouldExpandLOLIfLowerCase() {
when(session.getNextMessage()).thenReturn("Expand lol please");
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(),
equalTo("Expand laughing out loud please"));
}
This
forced
use
of
java.u1l.regex.Pa6ern
to
handle
case
insensi1vity.
public String getNextMessage() {
String msg = session.getNextMessage();
return Pattern.compile("LOL”, Pattern.CASE_INSENSITIVE)
.matcher(msg).replaceAll("laughing out loud");
}
18
Copyright © 2010 Sterling Barton. All rights reserved.
18

23. Don’t
Expand
“Lol”
–
Mixed-­‐Case
@Test
public void shouldNotExpandLOLIfMixedCase() {
String msg = "Do not expand Lol please";
when(session.getNextMessage()).thenReturn(msg);
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(), equalTo(msg));
}
This
forced
me
to
stop
using
Pa6ern.CASE_INSENSITIVE
flag
in
pa6ern
compila1on.
Only
use
“LOL”
or
“lol”
for
replacement
criteria.
public String getNextMessage() {
String msg = session.getNextMessage();
return Pattern.compile("LOL|lol").matcher(msg)
.replaceAll("laughing out loud");
}
19
Copyright © 2010 Sterling Barton. All rights reserved.
19

24. Don’t
Expand
“LOL”
If
Inside
Word
@Test
public void shouldNotExpandLOLIfInsideWord() {
String msg = "Do not expand PLOL or LOLP or PLOLP please";
when(session.getNextMessage()).thenReturn(msg);
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(), equalTo(msg));
}
The
pa6ern
matching
is
now
modified
to
use
spaces
around
each
varia1on
of
valid
LOL
shorthand.
return Pattern.compile("sLOLs|slols").matcher(msg)
.replaceAll("laughing out loud");
20
Copyright © 2010 Sterling Barton. All rights reserved.
20

25. Expand
“LOL”
If
Not
Inside
Word
@Test
public void shouldExpandIfSurroundingCharactersAreNotLetters() {
when(session.getNextMessage()).thenReturn("Expand .lol! please");
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(),
equalTo("Expand .laughing out loud! please"));
}
The
final
implementa1on
of
pa6ern
matching
code
looks
as
follows.
return Pattern.compile("bLOLb|blolb").matcher(msg)
.replaceAll("laughing out loud");
21
Copyright © 2010 Sterling Barton. All rights reserved.
21

26. Quality Debt
“Promises make debt, and debt makes promises.” - Dutch Proverb
22
22

27. Effect of Project Constraints on Quality
© 2009-2010, 23
23

28. Effect of Project Constraints on Quality
© 2009-2010, 23
23

29. “For every [dollar] of competitive advantage gained by
cutting quality, it costs $4 to restore it; and software is
an organizational asset and decisions to cut quality
must be made by executive management and
reflected in the financial statements.” - Ken Schwaber
© 2009-2010, 24
24

30. Acceptance Test-Driven Development
© 2009-2010, 25
25

31. Configuration Management Debt
“If releases are like giving birth, then you must be doing something wrong.”
- Robert Benefield
26
26

32. The Power of 2 Scripts: Deploy and Rollback
© 2009-2010, 27
27

33. Design Debt
Design decays when not attended to so design software continually
28
28

34. The value of technical aspects in an application or its
surrounding infrastructure is the cost of not
addressing them.
© 2009-2010, 29
29

35. * Abuse User Stories
Implement Security
for User Information
* From “User Stories Applied” presented by Mike Cohn Agile 2006
© 2009-2010, 30
30

36. * Abuse User Stories
As a Malicious Hacker I
Implement Security
want to steal credit card
for User Information information so that I can
make fraudulent charges
* From “User Stories Applied” presented by Mike Cohn Agile 2006
© 2009-2010, 30
30

37. Abuse Story Writing Workshop
Identify a user role who will try to abuse the application.
Set a time box of 30 minutes to 1 hour for generating abuse stories.
As pairs or individually, assume persona of the abuser role and
brainstorm as many abuse stories as possible. This should take 5 to 15
minutes.
As a team, identify abuse stories that are not valid or are duplicates and
remove them. This should take 10 to 20 minutes.
Prioritize abuse stories in terms of impact or value. Do this fast as
possible.
Give all abuse stories in priority order to the Product Owner to be
prioritized in the Product Backlog. Provide clarification on abuse stories
that the Product Owner does not understand well.
© 2009-2010, 31
31

38. Some Potential Abusers
Malicious Hacker
Mass of users
SQL injector
Disgruntled employee
Naïve API user
Impatient clicker
Denial-of-service (DoS) attacker
Sleazy user
© 2009-2010, 32
32

39. Lack of emphasis on software quality attributes
contributes to decay
© 2009-2010, 33
33

40. Software Quality Attributes Defined
© 2009-2010, 34
34

41. Software Quality Attributes Rating Tool
© 2009-2010, 35
35

42. Platform Experience Debt
“As in Nature, if an organization is too inflexible or stands still too long it will get
eaten.” - James Burke (author and historian)
36
36

43. Rather than creating teams to work on projects, let’s
find ways to give projects to cross-functional teams.
© 2009-2010, 37
37

44. Component Team Configuration
“Component Team” structure
Separate Product Backlog
Managing dependencies is often
serialized
Problematic integration issues
are
typically faced if multiple
components are
required to release
Use an “Integration
Team” to pull
components together
Causes more rework than
“Feature Team” structure
© 2009-2010, 38
38

45. Feature Team Configuration
“Feature Team” structure
Uses common Product
Backlog
Integration is done in parallel
Requires high levels of
communication across teams
to resolve integration issues
Forces Product Owners to
be more coordinated
Sprints should be
synchronized
Cross team fertilization is a
requirement to successfully
deliver in parallel
© 2009-2010, 39
39

46. Principles for Managing Software Debt
Maintain one list of work
Emphasize quality
Evolve tools and infrastructure continually
Improve system design always
Share knowledge across the organization
And most importantly, get the right people to work on your software!
© 2009-2010, 40
40

47. Thank you
Questions and Answers
41
41

48. Chris Sterling – Sterling Barton, LLC
Partner, Sterling Barton, LLC
Author of Book “Managing Software
Debt: Building for Inevitable
Change”
Consults on software technology,
Agile technical practices, Scrum,
and effective management
techniques
Email: chris@sterlingbarton.com
Certified Scrum Trainer Web: http://www.agileevm.com
http://www.sterlingbarton.com
Blog: http://www.gettingagile.com
Innovation Games® Trained Follow me on Twitter: @csterwa
Facilitator
Open Source Developer
© 2009-2011, 42
42