Embed Size (px)
Citation preview
TECHNICAL DEBT: HOW TO AVOID
PAINTING YOURSELF INTO A
PRODUCT CORNERMICHAEL DOUGHERTY
JEFF SHURTS
STRATEGY BUILD INTEGRATE TEST MANAGE
Our mission is to make
enterprises more efficient.
Our
Expert
ise
MOBILE DATA CLOUD SOCIAL
Our Services
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
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
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
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”
TECHNICAL DEBT VISUALIZED
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
NAIVE DEBT EXAMPLES
• Lack of experience
• Copy/paste programming
• Poor estimation
• Conforming to existing software’s poor design
UNAVOIDABLE DEBT EXAMPLES
• Scope Creep
• Third Party estimates
• Change in team makeup
• Late integration
• New and updated development tools and methodologies
• New design patterns
STRATEGIC DEBT EXAMPLES
• Pressure to deliver
• Management that requests a team to work beyond their
capabilities
• Survival measures
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”
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
LET’S PLAY A GAME
ARE THERE ANY TECHNICAL DEBT
“HORROR STORIES” TO SHARE?
SO WHAT CAN WE DO?
TECHNICAL DEBT MUST BE MANAGED
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
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)
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
MAKING TECHNICAL DEBT VISIBLE
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
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
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
NUMERICAL COMPARISONCost 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$
QUANTIFYING TECHNICAL DEBTBalance 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
NOT ALL TECHNICAL DEBT SHOULD BE
REPAID
• Product Nearing End of Life
• Throwaway Prototype
• Product Built for a Short Life
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…
JEFF SHURTS
TECHNICAL DEBT - A TECHIE’S PERSPECTIVE
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.
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.
A SIMPLE METAPHOR…
What you think the data
center looks like:
A SIMPLE METAPHOR…
What the data
center really looks
like:
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.
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.
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.
IN SUMMARY
CONTACT INFO / RESOURCES
Michael Dougherty – [email protected]
Twitter: @doughertymic
Jeff Shurts – [email protected]
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
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
233 S. Wacker Drive | Suite 3500
Chicago, IL 60606
312.756.1760
www.SPR.com
MICHAEL DOUGHERTY
JEFF SHURTS
