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 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.
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]. 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.
Example Memes!!! Indingo Montoya
SPR Consulting Technical Debt
TECHNICAL DEBT: HOW TO AVOID
PAINTING YOURSELF INTO A
STRATEGY BUILD INTEGRATE TEST MANAGE
Our mission is to make
enterprises more efficient.
MOBILE DATA CLOUD SOCIAL
• 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
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
“It’s the Karma of Coding: Pay later for what you do now”
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
• Strategic technical debt – Management decision due often to
o Pressure to meet deadlines
o Attempts to unreasonably accelerate velocity
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
• 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
• Universal Frustration
• End Users “Got No Satisfaction”
• 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
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
• 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
• 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
• Continuous Integration – Teams integrate their work as
frequently as is practical (small delivery batches)
MANAGING THE ACCRUAL OF TECHNICAL
• Refactoring – Restructure existing computer code without
changing its behavior to simplify and improve code
• 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
• 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
• 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
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
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$
QUANTIFYING TECHNICAL DEBT
Cash 650000 700000
Accounts receivable 450000 500000
Tools and Equipment 250000 300000
Total 1350000 1500000
Total Assets 1350000 1500000
Notes Payable 100000 120000
Accounts Payable 75000 85000
Short Term Technical Debt 75000 100000
Total 250000 305000
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
• 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…
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
A SIMPLE METAPHOR…
What you think the data
center looks like:
A SIMPLE METAPHOR…
What the data
center really looks
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
BE A “PROGRAMMER WHISPERER”
There are things we need to understand about the
• 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
• 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.
CONTACT INFO / RESOURCES
Michael Dougherty – email@example.com
Jeff Shurts – firstname.lastname@example.org
• 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-
• Huffington Post - http://www.huffingtonpost.com/steve-
233 S. Wacker Drive | Suite 3500
Chicago, IL 60606