1. TECHNICAL DEBT: HOW TO AVOID
PAINTING YOURSELF INTO A
PRODUCT CORNER
MICHAEL DOUGHERTY
JEFF SHURTS
2. STRATEGY BUILD INTEGRATE TEST MANAGE
Our mission is to make
enterprises more efficient.
Our
MOBILE DATA CLOUD SOCIAL
Our Services
3. AGENDA
• What is technical debt?
• The primary types and causes of technical debt
• The consequences of technical debt
• Communicating the impact of technical debt
• Managing technical debt
4. WHAT IS TECHNICAL DEBT?
A term used to describe the obligation that a software organization
incurs when it chooses a design or construction approach that is
expedient in the short term but that increases complexity and is
more costly in the long term
5. TECHNICAL DEBT
LAYMAN’S DEFINITION
The impact of developing an imperfect product
over time that becomes harder to maintain until
the point where it becomes unmaintainable
6. TECHNICAL DEBT INCLUDES
• Unfit or bad product design
• Product defects
• Incomplete testing
• Poor integration and release management
• Lack of system / platform experience
• Good Developers, Bad Developers and even Excellent
Developers!
“It’s the Karma of Coding: Pay later for what you do now”
8. TYPES OF TECHNICAL DEBTCAUSES
1. Naïve technical debt
2. Unavoidable technical debt
3. Strategic technical debt
• Naïve technical debt – Lack of experience
• Unavoidable technical debt – advancements not available at
the time
• Strategic technical debt – Management decision due often to
o Pressure to meet deadlines
o Attempts to unreasonably accelerate velocity
10. UNAVOIDABLE DEBT EXAMPLES
• Scope Creep
• Third Party estimates
• Change in team makeup
• Late integration
• New and updated development tools and methodologies
• New design patterns
11. STRATEGIC DEBT EXAMPLES
• Pressure to deliver
• Management that requests a team to work beyond their
capabilities
• Survival measures
12. CONSEQUENCES OF TECHNICAL DEBT
• Increased Time to Delivery
• Rising Development and Support Costs
• Significant Number of Defects
• Unpredictable Tipping Point
• Product Atrophy
• Decreased Predictability
• Underperformance
• Universal Frustration
• End Users “Got No Satisfaction”
13. TECHNICAL DEBT
FINANCIAL COMPARISON
• Maintaining an application without any unit tests is like
borrowing money each time you add or change a line of code
• Skipping design phase is like borrowing money to get a very
“quick” and “predictable” return of investment
• Refactoring is like paying down the principal
• Development productivity decreases when interests grow up
• Managers don’t care about code quality, just ask them to pay
the debt in order get their attention
• Bankruptcy is logical extension of technical debt uncontrolled…
we call it a system rewrite
19. PAYING TECHNICAL DEBT
• Happened-upon Technical Debt – Debt the team was unaware
of until exposed during normal maintenance.
• Known Technical Debt – Known by the development team and
made visible
• Targeted Technical Debt – Known by the development team
and targeted for servicing by putting into the product backlog
• “Suddenly Born” Technical Debt – Code built on assumptions
that changes with new requirements
20. MANAGING THE ACCRUAL OF TECHNICAL
DEBT
• Simple Design – Follow standard software design patterns
• Code Reviews – Reviews of source code by peers to increase
quality and decrease technical debt
• Pair Programming – Address debt together while coding
• (A)TDD / BDD – (Acceptance) Test Driven Development and
Behavior Driven Development to incorporate testing and
requirements validation that initially fail as the code is built
• Automated Testing – Ensure new development does not break
existing functionality
• Continuous Integration – Teams integrate their work as
frequently as is practical (small delivery batches)
21. MANAGING THE ACCRUAL OF TECHNICAL
DEBT (CON’T)
• Refactoring – Restructure existing computer code without
changing its behavior to simplify and improve code
maintainability
• Clear Definition of Done – This should include guidelines for
code that has been reviewed and refactored
• Code Guidelines – Coding conventions for standard practices
and principles which include naming conventions
• Standard naming Conventions – Consistency of code
development to simplify maintenance & remove technical debt
• Documentation – Incremental documenting
• Retrospectives – Focus on Technical Debt improvements
23. MAKING TECHNICAL DEBT VISIBLE
• Show declining velocity due to not addressing technical debt
• Explain how cost of incremental time to repay debt and lifetime
interest payments for not addressing technical debt early
• Do a direct comparison of addressing technical debt versus
avoiding technical debt
• Remember to put as much detail and estimation process as
possible
• Tools like SonarQube can help the team with the time (and
therefore cost) it will take to pay the debt
24. MANAGING THE ACCRUAL OF TECHNICAL
DEBT - TOOLS
• SonarQube – Will give a general technical debt calculation
• The team will have to augment this calculation since it is incomplete and
doesn’t factor team capacity and specifics of technical debt
• However, SonarQube addresses the seven “deadly sins of
source code quality” with this tool
1. Bad distribution of the complexity
2. Duplications
3. Lack of Comments
4. Coding Rules violations
5. Potential Bugs
6. No or Useless Unit Tests
7. Bad Design
25. MANAGING THE ACCRUAL OF TECHNICAL
DEBT - TOOLS
• CAST – Measures Technical Debt
• Per the CAST Research Labs, the average Technical Debt per Line of
Code (LOC) is $3.61
26. NUMERICAL COMPARISON
Cost Manage Debt Ignore Debt
Monthly Development Cost 100,000.00$ 100,000.00$
Total Development Months 13 10
Total Development Cost 1,300,000.00$ 1,000,000.00$
Delay in months (to release) 3 0
Delay cost per month 150,000.00$ 150,000.00$
Total delay cost 450,000.00$ -$
Debt-servicing months 0 4
Debt-servicing cost -$ 400,000.00$
Total cost in lifecycle profits 1,750,000.00$ 1,400,000.00$
Delay cost of incremental time to repay debt -$ 150,000.00$
Lifetime interest payments on technical debt -$ 400,000.00$
Other debt-related costs -$ 50,000.00$
Real cost in lifecycle profits 1,750,000.00$ 2,000,000.00$
27. QUANTIFYING TECHNICAL DEBT
Balance Sheet
FY-2015 FY-2016
Current Assets
Cash 650000 700000
Accounts receivable 450000 500000
Tools and Equipment 250000 300000
Total 1350000 1500000
Total Assets 1350000 1500000
Current Liabilities
Notes Payable 100000 120000
Accounts Payable 75000 85000
Short Term Technical Debt 75000 100000
Total 250000 305000
Long-term Liabilities
Notes Payable 300000 320000
Long Term Technical Debt 700000 925000
Total 1000000 1245000
Total Liabilities & Stockholder Equity 1250000 1550000
28. NOT ALL TECHNICAL DEBT SHOULD BE
REPAID
• Product Nearing End of Life
• Throwaway Prototype
• Product Built for a Short Life
29. TECHNICAL DEBT SERVICING GUIDELINES
• Apply the Boy Scout Rule
• Repay Technical Debt Incrementally and frequently
• Repay the High Interest Technical Debt first
• Never, ever pay debt for unused features
• Repay Technical Debt while still delivering Features
It’s like a tight rope walk where spending not enough time will lead
to issues and spending too much time is wasteful…
32. A SIMPLE METAPHOR…
• You, the Product Owner of a mid-sized data
center, need to replace a couple servers in the
main rack, as they are near end-of-life.
33. A SIMPLE METAPHOR…
• Your IT guy tells you it’s going to take a week.
You can’t imagine why – it’s quite a simple
request.
36. ALL THAT TO SAY THIS…
As Product Owners and
ScrumMasters, it’s hard
to know when
developers are “making
excuses,” and when they
really have legitimate
concerns.
37. BE A “PROGRAMMER WHISPERER”
There are things we need to understand about the
developer psyche:
• We want to deliver great things!
• We want to exceed expectations!
• We are inherently lazy – and that’s a good thing!
• We can tend to see the world through a binary, “it’s
good or it’s crap” lens.
38. TRUST US, BUT BE INQUISITIVE
• Do give us the time we need to maintain a tidy house.
We live in it every day, and it will help us help you.
• Don’t allow us to let perfect be the enemy of good.
• Be on the lookout for violations of other Agile principles
like YAGNI.
• Keep us honest. If you give us time to refactor or clean
up a code base, expect our estimates for related work
to be decreased. If you have time and patience to do it,
actually measure the ROI of a large refactoring effort.
40. CONTACT INFO / RESOURCES
Michael Dougherty – michael.dougherty@spr.com
Twitter: @doughertymic
Jeff Shurts – jeff.shurts@spr.com
Twitter: @pknbo864
• Essential Scrum – Kenneth Rubin
• Managing Software Debt: Building for the Inevitable – Chris Sterling
• Wikipedia – Technical Debt, Acceptance Test Driven Development
• Martin Fowler - http://martinfowler.com/bliki/TechnicalDebt.html
• Clean Code – Robert C. Martin
41. RECENT NEWS ARTICLES
• Software Development Times - http://sdtimes.com/technical-
debt-care/
• Huffington Post - http://www.huffingtonpost.com/steve-
blank/organizational-debt-is-li_b_7317728.html
42.
43. 233 S. Wacker Drive | Suite 3500
Chicago, IL 60606
312.756.1760
www.SPR.com
MICHAEL DOUGHERTY
JEFF SHURTS
Editor's Notes
BUILD 1&2: WHO WE ARE Our goal to make enterprise more efficient. SPR Consulting helps you capitalize on advances in cloud, mobile, data and social.
BUILD 3: HOW TO ENGAGE WITH US Our engagement model addresses the lifecycle of your initiatives– We help when you need support with strategic thinking, when you need to build a technology or when you have multiple systems that need to be integrated. We firmly believe that testing has to be part of an overall engagement model and once systems are up and running, we manage your environments.
ASK HOW MANY KNOW TECHNICAL DEBT
Managing software debt & communicating and managing is where the real work is centralized.
Technical debt is a serious problem!!!
Not here to simply espouse about the problem, but give ideas for solving the problem.
How many people are familiar with Technical Debt? Raise of hands please.
How many people own clothes or have a closet? Now THAT’S better!
Wikipedia definition: Technical debt (also known as design debt[1] or code debt) is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.
Technical Debt is like your teeth with eating; your teeth will wear out over time unless you maintain them
Common causes of technical debt include (a combination of):
Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes.
Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications.
Lack of building loosely coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.
Lack of test suite (DETESTABLE), which encourages quick and risky band-aids to fix bugs.
Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid.
Lack of collaboration, where knowledge isn't shared around the organization and business efficiency suffers, or junior developers are not properly mentored
Parallel development at the same time on two or more branches can cause the buildup of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.
Delayed refactoring – As the requirements for a project evolve, it may become clear that parts of the code have become unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.
Lack of alignment to standards, where industry standard features, frameworks, technologies are ignored. Eventually, integration with standards will come, doing sooner will cost less (similar to 'delayed refactoring').
Lack of knowledge, when the developer simply doesn't know how to write elegant code.
Technical Debt ARE NOT BUGS!!!! They aren’t defects, errors or functional glitches. Instead, they are the how the product is put together.
Think of the movie, “The World’s Fastest Indian” with Anthony Hopkins, a story of Burt Munro, who achieved a speed of 305 mph on an Indian motorcycle originally designed to not go over 55 mph.
Big Ball of mud - is a software system that lacks a perceivable architecture.
Spaghetti code, Lasagna code and Ravioli code
Software rot - also known as code rot, bit rot, software erosion, software decay or software entropy describes the perceived "rot" which is either a slow deterioration of software performance over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or otherwise called "legacy" and in need of upgrade.
Three primary types and related causes.
YOU CAN’T GET IT RIGHT THE FIRST TIME AROUND
Trying to do that bring in a waterfall styled model which still take rework
Naïve debt is often accidental, but just as deadly.
20 minutes into presentation
Debt builds on debt and will often increase exponentially after a certain tipping point.
Cite examples from Corptax and their product.
There are tools to help identify technical debt – duplication, broken/circular references
Technical debt is INVISIBLE to the customer (and often business stakeholders) and therefore not considered to be a problem that needs addressing.
However, coding is fragile, like any machine and needs to be maintained with tune-ups, otherwise it will break down and become useless.
http://www.agilistapm.com/understand-technical-debt-by-playing-a-game/
Points: Frequency reduces difficulty
Ask for user input!
It’s an ART to properly manage technical debt, but can be done with guidelines of not doing enough to doing too much.
Broken out the three classifications of Technical Debt Management
Paying TD
Accrual of TD
Making TD visible
Three types of technical debt that will be paid.
Happened upon – should be addressed when found or logged into the technical debt backlog for later
Known TD – Part of the backlog to be evaluated and prioritized
Targeted TD – Ready to be serviced
Design patterns – Algorithm strategy, Computational Design, Execution, Implementation Strategy and Structural Design
ATDD is closely related to Test-Driven Development[TDD].[7] It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding.
A requirement that lacks a test may not be implemented properly. A test that does not refer to a requirement is an unneeded test. An acceptance test that is developed after implementation begins represents a new requirement.
Component Tests and Unit Tests
GIVEN/WHEN/THEN format of ATDD acceptance criteria
By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain code.
Use the “five whys” with five corrective actions to assess and manage technical debt – Go into each answer given with a further “why” to get more detail on how to solve
Refactoring is like working out for keeping your health
Refactoring has a strict definition: changing internal structure without changing external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex
conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, etc. Refactoring with confidence is only possible with automated test coverage. Neglecting refactoring makes it hard to change the product in the future, especially since it’s hard to find good developers willing to work on bad code.
Unfortunately, many organizations don’t understand the affects of technical debt.
Here’s an example of showing technical debt, but MOST BUSINESS MANAGEMENT DON’T CARE ABOUT THIS
So how to make leadership care???
Must find a way to communicate the magnitude of a product’s technical debt in a way that the business people can understand.
Lifetime interest payments is the continual additional costs to workaround technical in the form of less productivity.
Example of how Technical Debt can be numerically represented that will get leadership attention.
Debt Servicing months – Extra time to pay accrued debt
Delay cost of incremental time to repay debt – cost in time to pay for the debt later (estimated one month longer)
Lifetime interest payments on technical debt – The future cost in delaying the RELEASE of new features due to addressing technical debt
Other debt related costs – Maintenance and other integration costs for postponing future delivery of features
When deciding, err on the side of not taking on the debt. Most organizations substantially underestimate the true cost of assuming technical debt and aren’t nearly as diligent as they think they will be at repaying it.
Consider both the short term and long term consequences of technical debt for sustained products.
Current year - $100k in the green due to lower technical debt
Next year - $50k in the red due to higher technical debt
This will get substantially worse unless TD is properly taken care of in the future
Technical debt should be addressed for products that are meant to last a long time and have a high standard of quality that helps with sales.
Budget in technical debt repayment into team’s delivery capacity
Don’t fall into the trap of having “technical debt sprints” unless your technical is very high and there is no other recourse
There is no one-size-fits-all formula for managing software debt.
Don’t let Technical Debt take your organization by surprise – it can grow into a very huge elephant
Managing technical debt leads to architectural agility and enable software to be built for changing conditions.
