Technical debt plagues many software projects - but others are held back by more critical issues. Increase your software delivery efficiency by moving beyond technical debt!

1. Beyond Technical Debt
The interest we pay on our failures.
April 17, 2013

2. Technical Debt
 Ward Cunningham suggested the term “technical debt” to refer
to the cutting of corners when you build software.
 His premise was that if you cut corners, the shoddy work would
accumulate in the form of “interest” that needed to be paid on
the “principal”, much like a financial debt.
 Some use the term to describe shortcuts they intend on taking,
while others use it as a historical view to identify what has
already accumulated.
April 17, 2013

3. Accumulation of Debt
 We find the concept of technical debt useful to describe the
‘sins of the past’ and to encourage our customers to clean up
the debt or they’ll pay the price
 Clearing up the debt comes in many shapes:
 Taking time to refactor code bases
 Document the system
 Revisit the non-functional requirements / re-architect
 Replace an outdated component or technology
April 17, 2013

4. The Real Debt Threat
In addition to the traditional technical debt, we’ve encountered
new forms of debt that plague software delivery teams
1. Organizational Debt 5. Tooling Debt
2. Personnel Debt 6. Automation Debt
3. Process Debt 7. Testing Debt
4. Practice Debt 8. Operations Debt
April 17, 2013

5. Organizational Debt refers to ineffective
organizational structures that obstruct the efficient delivery of
work.
 Many organizational hierarchies are ancient relics. They haven’t
been changed to reflect new work patterns.
 Some organizations are designed around office politics.
 Conway’s Law suggests that our deliverables reflect the
organizational structure that created it.
Let software processes drive the organizational design.
April 17, 2013

6. Personnel Debt refers to organizations that have the
wrong people, leading to inefficient delivery.
 Poor hiring practices let the wrong people in the door.
 Poor firing practices kept the wrong people in.
 Poor retention and training practices failed to get the most out
of the good people.
An organization can clean up technical debt but if they have a
personnel debt problem, technical debt will come right back.
April 17, 2013

7. Process Debt refers to organizations that have the wrong
delivery processes: Too much, not enough, or just wrong.
 Some still using “agile” to mean “process free”
 Many stuck in older methods (waterfall, RUP, etc.)
 Few have Introduced cross-cutting process owners (such as
crossing DevTestOps)
It’s easy to detect a good process – and a bad one. It’s much
harder to define one and keep it around.
April 17, 2013

8. Practice Debt refers to organizations that fail to
accumulate and disseminate best practices to their teams.
 “Those who fail to learn from the past are condemned to repeat
it.” – we must document tacit knowledge and leverage it.
 The body of knowledge gets stale. Out with the old and in with
the new.
 Only the most important practices should be enforced as policy.
Those who want to establish a TRUE culture should think more
about institutionalizing knowledge.
April 17, 2013

9. Tooling Debt refers to organizations that don’t have the
right tools or platforms for the job at hand.
 “If all you have is a hammer, everything looks like a nail.”
 Some organizations have failed to refresh the tools needed.
 Other organizations have gone “tool crazy”; they have too many
tools to get knowledgeable on any one of them.
Languages, IDE’s, Platforms and other tools make us efficient but
only when we find the right balance.
April 17, 2013

10. Automation Debt refers to organizations that
continue to do things by hand that should be automated.
 No continuous builds.
 No continuous delivery.
 No automated operational recovery.
 Tool chain isn’t integrated.
Our industry is going through a rebirth in how we automate the
software development process and connect it to infrastructure
and platforms: DevOps + Software Defined Computing
April 17, 2013

11. Testing Debt refers to organizations that built software
but did inadequate testing.
 System lacks unit or functional tests.
 System lacks operational tests (perf, load, resilience, security)
 System lacks UI or usability tests
 Disaster recovery routines never tested
Debt associated with testing has a VERY HIGH interest rate. This is
a MUST FIX area.
April 17, 2013

12. Operational Debt refers to organizations that create
systems that are hard/expensive to operate in a production setting.
 System wasn’t properly instrumented (logs, monitors, …)
 Didn’t plan for patches or versioning up-front
 System was hard-coded to specific hardware/platforms and can’t be
easily moved to new gear or DC locations
 System only runs on most expensive gear or platforms
Developers make mistakes but it shows up in operations budget. Huge
opportunity to save money in this area!
April 17, 2013

13. Declaring Bankruptcy or Paying off the Debt
 On occasion, we find a software system that has accumulated
large technical debts. Business owners are forced to make a
decision: Declare bankruptcy or pay off the debt.
 Remember: It’s not just “technical (application) debt”.
 If the other eight types of debt are still in place, it’s likely that
any effort to fix technical debt will fail.
Don’t just fix technical debt. Do root cause analysis on
your whole environment!
April 17, 2013

14. MomentumSI Consulting
Consulting – Strategy - Delivery
 Assessment of current state, workshops and roadmaps
 Culture transformation: rethinking processes, incentives and systems
 Upgrading capabilities in continuous builds, testing and deployment
 Experts in modern tooling and implementation practices
For a briefing on our offerings, email: Jeff Schneider
jschneider@MomentumSI.com
Cloud - App Dev - Big Data - DevOps
April 17, 2013