Declan Whelan presented to KWRuby meeting on February 17. He spoke about how to deal with technical debt in agile software projects:

• Declan is a director of Agile Alliance, who recently met in Costa Rica
• he is also co-chairing an Agile Alliance tech debt working group, which is a focus for him in 2016

Definition

• old code bases tend to have lots of debt which slows down development
• Martin Fowler described the tech debt quadrants (i.e., deliberate vs inadvertent, reckless vs prudent)
• the term was originally coined by Ward Cunningham when describing technical trade-offs to the financial people on a project
• Declan's definition is: anything in the code that slows me down
• code which does not map well to the problem domain
• badly written code, however, should not be considered technical debt (e.g., not tests, not TDD, not SOLID
• Simon pointed out that technical debt can slow down paying feature debt, and that it can change as features change over time
• Domain Driven Design(DDD) can help my continuously driving the code back towards the problem domain

Measuring

• there are various software metrics which can be used measure/estimate technical debt (e.g., various kinds of static analysis, churn analysis)
• the Agile Alliance working from is trying to develop tools for analyzing finance and risk related to technical debt in a project
• Garter wrote a technical debt report in 2010
  • estimated the global cost of technical debt was $500 billion, and expected it to rise to $1 trillion by 2015
• a more informally definition could include
  • how happy are you in the code
  • what % of time is wasted
  • what would it take to fix

Dealing with it

• increasing tech debt will increase the desire for a re-write and it is well establish that a re-write can be VERY risky
  • this is something that Declan has seen in large companies
• it is a deeper problem than "our developers write crappy code"
• What are the underlying reasons?
  • system archetypes
  • shifting the burden
• over time is gets hard to do fundamental fixes
  • this gets worse unless there is specific push back on this
• our cognitive bias of recency bias, leads us to short term/fast solutions
  • one strategy is to not offer short term/faster options to client, because they will always chooser faster
• forward looking leaders are important to choosing slower but longer term solutions
• legal liability may eventually apply some pressure
  • Uncle Bob had discussed this before
  • Declan did an interviewed with [Martin Fowler] and Uncle Bob at Remote Agile Conference
  • maybe some big catastrophic event will precipitate this
• avoid short term project which build on underlying products
  • this encourages the short term choices
  • instead align team/projects to maintaining the products over the long term
• Test Driven Developer(TDD) is a useful tool for guiding your code towards the better long term choices

• [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development) has been a problem because is frequently adopted as a management practise without also adopting a corresponding technical process (i.e., Agile engineering practices, XP) such as:

  • Test Driven Developer(TDD)
  • Pair programming
  • refactoring
  • simple design principles
  • passes all the tests.
  • expresses every idea that we need to express
  • says everything once and only once (or Don't Repeat Yourself{DRY})
  • has no superfluous parts.
  • collective ownership
  • coding standards
  • automated customer tests (or acceptance tests
  • Continuous Integration

• some suggestions from the audience for helping with technical debt

  • business agreement
  • static analysis
  • explicitly organized dealing with technical debt with epics, sprints, or chore stories
  • education