1. 1

2. Agenda
2

3. About me
3

4. What’s going on?
• Start a little slow
• Quickly pick up - A lot of features are getting developed
• Things start to slow down
• Can’t seem to recover
• These are signs of bad code and technical debt
4

5. Adding new features or simple changes take forever
Picture: http://www.flickr.com/photos/49531720@N00/247730111/
5

6. Delivery dates are missed
Picture: http://www.flickr.com/photos/89306448@N00/2247180420/
6

7. Bugs increase
Picture: http://www.flickr.com/photos/71962092@N00/2874328851/
7

8. Team is frustrated
Morale is low
Picture: http://www.flickr.com/photos/16857236@N03/2429136239/
8

9. Customer is unhappy
9

10. Uncle Bob provides the following attributes of bad code:
Rigidity – difficult to change. A change causes a cascade of subsequent changes in
dependent modules. Result -> manager fear to fix non critical problems because no
reliability on impact and how long it will take. This lead to rigidity.
10

11. Fragility – closely related to rigidity. Software tends to break in many places every
time it is changed. Even in areas that are conceptually unrelated. As this increases,
software becomes impossible to maintain because every fix introduces 5 new bugs.
This leads to distrust and a loss of credibility.
11

12. Developers end up playing whack-a-bug.
Picture: http://www.flickr.com/photos/tpapi/2765541278/
12

13. Immobility – inability to reuse software from other parts of the system. Need module
similar to another one already written, however, module has too much baggage. It is
hard and risky to separate desirable part from undesirable part so decide to rewrite
instead of reuse.
Picture: http://www.flickr.com/photos/97041449@N00/5261698908/
13

14. Viscosity – design (when faced with a change, take easy way(hack) or hard way)
Environment-
• If compile time is long, make changes that do not force large recompile
• If check-in takes a long time, make as few check ins as possible
• If deployment is difficult, make changes in database.
• End up applying the easiest change to avoid environment issues even if change is in
the wrong place.
14

15. Reasons for bad code:
Excuses about deadlines – no time to test, no time for design change
15

16. Broken Window Theory:
Police in NYC conducted a study
1. Parked a car in a bad neighborhood and observed
2. Nothing happened for a couple of days
3. Police broke small rear window and observed
4. Within 4 hours, car was stripped
Picture: http://www.flickr.com/photos/7389424@N05/2351559480/
16

17. http://www.flickr.com/photos/24293932@N00/1144691293/
17

18. Broken window theory also applies to code.
1. Start out and things are clean
2. Once you introduce one sign of bad code, things quickly get out of hand
As developers, we’ll say, well we are already doing things wrong here, so it does not
matter if we do it wrong here as well.
Soon things spread and get out of control.
Picture: http://www.flickr.com/photos/17454738@N00/2245445147/
18

19. Over architecting:
• Attempt to envision all possible future scenarios
• Create unnecessary layers of complexity to support things that are not really
requirements
• Tempted to design solutions to problems in advance of their needs
• Program goes in a different direction and code is written without benefit
• Code doesn’t really fit need because written before problem well understood
• Overdesign takes extra time and produces code that is either unused or doesn’t fit
the needs of the project
19

20. Sometimes design is bad and instead of stopping to fix we continue building on top of
it and create an even bigger mess.
Picture: http://www.flickr.com/photos/25196025@N00/381877979/
20

21. Poor skills or lack of proper training is also a major contributor
http://www.flickr.com/photos/25507200@N07/3120849218/
21

22. Technical debt by Ward Cunningham
22

23. 23

24. Principal: Cost due to amount of time we need to code it the right way
Interest: Cost due to amount of extra time we spend to work with something not
coded the right way
If it costs the same (no interest), it is just differed work and not technical debt
24

25. Jim Highsmith about technical debt in terms of impact on Cost of Change
25

26. We trade on quality daily. Have option to buy quality watch, but decide to buy cheaper
one with out knowing what is inside. No visibility into internal quality.
Picture: http://www.flickr.com/photos/39516732@N08/4666623572/
26

27. Looks the same, and cheaper!
Picture: http://www.flickr.com/photos/64211362@N02/6338814898/
27

28. Martin Fowler about design stamina hypothesis:
• Some benefit by ignoring good design
• Soon productivity flattens out
• Good design route starts out slower, but soon becomes almost linear
• Intersection is design pay-off line
• If above the line, no longer makes sense to ignore good design decision
• Trick to know how far from line.
• Martin estimates in most cases this is in magnitude of weeks not months or years
28

29. Is all technical debt bad?
Quick and dirty or clean? Which one would you choose?
It depends…
29

30. 30

31. 31

32. 32

33. 33

34. 34

35. • Not all technical debt is bad
• Loans to buy a house or a car are generally considered good loans
• We want to be responsible in our decisions
35

36. Martin Fowler introduces the technical debt quadrant:
1. Inadvertent/Reckless: Don’t know that they are doing something wrong
2. Deliberate/Reckless: Know it wrong and continue to do it
3. Deliberate/Prudent: Make conscious decision to take on debt due to specific
business need
4. Inadvertent/Prudent: With the best of intentions, things did not go well (rare)
Most people are in quadrant 1 and 2 and we need to move them to 3.
There are good reasons to take on debt like a shorter time to market, preserving
startup capital, delaying development expenses
36

37. Types of debt
Unintentional debt: careless mistakes, and honest mistakes (bad judgment) – never a
good idea
Intentional debt – short term (focused and unfocused), long term
Only short focused and long term good debt
37

38. Flower shop website must be live 2 weeks before valentines day
Otherwise business will go under
Must take on debt to meet date
Will spend x weeks paying back debt while preparing for Mother’s day
38

39. • Make prudent and deliberate decision on debt
• Have plan to service debt
• Make our payments
• Avoid late payment notices
39

40. We don’t want to take on debt when we are behind schedule. This causes a vicious
circle
40

41. If debt not paid back, business shuts down or application will require re-write
Picture: www.flickr.com/photos/66622362@N00/3353570653/
41

42. 42

43. Step 1 - Register our debt
• Add shortcuts decisions to technical debt backlog
• Include estimated hours to do it the right way
• Add date of estimate because only valid if paid off immediately
43

44. 44

45. 45

46. We want to try to determine
Cost of clean way
Cost of dirty way
Savings now
Impact (interest rate)
Cost of fix later
Beware of Broken Windows
Avoid debt that is untrackable
Avoid low ROI
46

47. Step 2 – Evaluate existing code
Inspect and assess level of debt and also register it
47

48. Sonar – open source tool
48

49. Various metrics with drill down capabilities
49

50. Various metrics with drill down capabilities
50

51. Step 3 - monetize the debt
1. Estimate the amount of hours it takes to fix each type of deficit
2. Multiply by rate/hr
3. Multiply by the total number of items
51

52. Technical debt plugin in Sonar calculates it this way
52

53. Another plugin is the SQALE metric (Software Quality Assessment based on Life Cycle
Expectations)
that breaks things along characteristics (non functional requirements), sub
characteristics, and source code requirements
Changeability -> loose coupling or related changeability -> code duplication
Maintainability -> understandability -> redundant throws or simplifying Boolean
expressions, or unused variables
Security -> Errors -> preserving track trace, sql injection, or system.exit
Reliability - > unit test or exception handling -> unit test coverage, illegal throws
Testability -> unit level testability -> cyclomatic complexity
Efficiency -> memory usage -> correct data types or static final or string buffering
Portability -> software related portability -> imports, or locale
The method defines 4 key concepts:
1. The Quality Model: The SQALE Quality Model is used for formulating and organizing
the non-functional requirements that relate to code quality. It is organized in three
hierarchical levels. The first level is composed of characteristics, the second of sub-
characteristics. The third level is composed of requirements that relate to the source
code’s internal attributes. These requirements usually depend on the software context
and language.
53

54. 2. The Analysis Model: The SQALE Analysis Model contains on the one hand the rules
that are used for normalizing the measures and the violations relating to the code, and
on the other hand the rules for aggregating the normalized values.
3. The Indices: All indices represent costs. One represents the Technical Debt of the
application. Others are used to analyze that debt.
4. The Indicators: The method defines three summarized indicators. They have been
defined to provide a visual representation of the Technical Debt.
53

55. 54

56. 55

57. Costs can be customized for own environment
Future work:
Prioritization, based on impact.
Try to link cost vs. impact on business. Example, fixing non-initialized variable is low
cost, however, it can cause large damage
56

58. 57

59. 58

60. With dollar amount associated with technical debt, we can engage upper management
with a language they understand
59

61. Agile Triangle by Jim Highsmith
60

62. Technical debt triangle by Israel Gat
61

63. Step 4 – Establish debt limit
We can now have a conversation with the business in $$$ and talk about technical
debt and the impact on ROI.
Today about 70% of an organizations IT budget is spent on maintenance instead of
new development.
What is a good amount of debt?
It depends on appetite for risk.
Tension between business and tech
Biz optimistic about benefit and the cost of carrying the debt
Tech pessimistic about benefit and costs
Key is to manage and monitor it.
If reach certain threshold, then make major payments to get back on track and keep
debt under control.
62

64. Credit rating: based on teams ability to avoid unintentional technical debt
Acquired debt: merger with other companies, decisions made by others
90 day same as cash: if you fix it quickly there will be no interest payment
Low monthly payment: web vs. embedded software – ability to payoff debt depends
on type of software
Retiring debt: Once we retire system, there is no more debt. This is hard with financial
debt
Deficit programming
Technical Inflation: Failing behind in versions to the point where the code is no longer
compatible with the compiler
The key is that technical debt enables a conversation between the technical folks and
the business folks to make informative decision on code quality
63

65. Step 5 – Pay down debt
Where do we start?
64

66. Tool gives us information on where to focus
65

67. 66

68. 67

69. 68

70. Step 5a – Pay high interest debt 1st
Don’t quickly jump to fix most complex class. There are long term debt and short term
debt. 1st reduce short term debt which is like credit card debt.
Short term debt has highest interest rate. Tackle 1st the classes that are constantly
changing the most. The more changes we make the more interest we are paying.
Consider high minimum payment & required on going payment.
A class with no test coverage at all, or one that is very complex, but is never or rarely
modified, needs to be left on the side for now and is considered as a low interest debt.
Focus on the high interest 1st.
Picture: http://www.flickr.com/photos/23327787@N08/3027534098/
Picture: http://www.flickr.com/photos/37815348@N00/5398908333/
69

71. Step 5b – Pay down debt based on team skills
Does the team know how to write tests to increase code coverage?
Does the team know how to reduce complexity?
If not, come up with a training and coaching plan.
Does the team understand the rules they are violating? If so start their.
Do they know how to remove duplications?
It is going to depend, but the key is to put a plan and execute on it.
Also, don’t try to many things at once. This can be overwhelming.
1. Reduce debt while fixing bugs
2. Do not take on additional debt for new code
Picture: http://www.flickr.com/photos/51035555243@N01/155589939/
70

72. Approach:
Immediately after a release
10% of each iteration
Above certain threshold
Rotate individual
71

73. 72

74. 73

75. 74

76. 75

77. 77

78. Research for this presentation based mainly on the work of Robert Martin, Steve
McConnell, Israel Gat, Martin Fowler
78

79. 79

80. 80

81. 81

82. 82

83. 83