Managing technical debt notes

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

Adding new features or simple changes take forever

Picture: http://www.flickr.com/photos/49531720@N00/247730111/

5

Delivery dates are missed


6

Bugs increase


7

Team is frustrated
Morale is low


8

Customer is unhappy

9

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

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

Developers end up playing whack-a-bug.

Picture: http://www.flickr.com/photos/tpapi/2765541278/

12

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.


13

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

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

15

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


16

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

17

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.


18

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

Sometimes design is bad and instead of stopping to fix we continue building on top of
it and create an even bigger mess.


20

Poor skills or lack of proper training is also a major contributor

http://www.flickr.com/photos/25507200@N07/3120849218/

21

Technical debt by Ward Cunningham

22

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

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

25

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.


26

Looks the same, and cheaper!


27

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

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

29

• 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

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

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

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

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

39

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

40

If debt not paid back, business shuts down or application will require re-write

Picture: www.flickr.com/photos/66622362@N00/3353570653/

41

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

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

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

47

Sonar – open source tool

48

Various metrics with drill down capabilities

49

Various metrics with drill down capabilities

50

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

Technical debt plugin in Sonar calculates it this way

52

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

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

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

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

59

Agile Triangle by Jim Highsmith

60

Technical debt triangle by Israel Gat

61

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

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

Step 5 – Pay down debt
Where do we start?

64

Tool gives us information on where to focus

65

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.


69

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


70

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

71

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

78

Managing technical debt notes

More Related Content

What's hot (20)

Similar to Managing technical debt notes (20)

More from Fadi Stephan (20)

Recently uploaded (20)

Managing technical debt notes