Beyond technical debt


Published on

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!

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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 technologyApril 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 DebtApril 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 ComputingApril 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 Cloud - App Dev - Big Data - DevOpsApril 17, 2013