Technical Debt

• longer-term consequences of poor design decisions
• it is a real risk which can genuinely be incurred
• not all flaws and defects constitute technical debt, they don't reflect "design decisions" which were actually taken. They are often just errors
• If a decision doesn't directly compromise product quality, then it isn't technical debt: since it doesn't put the quality of the product itself at risk
• DoD is the primary bulwark against debt building up in the first place, should be sufficiently robust for unmanageable levels of genuine debt not to accrue
• if technical debt is known to be building up, the DoD should be revisited
• It's essential to find out why the debt is being incurred and how this can be avoided
• Increased by cut quality to meet deadlines or releasing undone work
• One way to control:
  • deciding how much work/including allowing time for refactoring (and indeed any other tasks)) they can induct into a Sprint Backlog without compromising long-term quality
• there's no prescription for how technical debt should be handled once you've got it
• Severe cases: debt may have been accumulated which exceeds the value of the project itself
  • Cancel the project and start again
  • whittle it down gradually, Sprint by Sprint
• Quality
  • Most software lacks quality for the simple reason that you cannot easily see the quality in software like you could with a table or a painting
  • If you put developers under pressure to deliver, they will continuously and increasingly cut quality to meet deadlines, vicious cycle
  • A lack of quality of the code results in an increase in Technical Debt (that becomes a vicious cycle)
    • 1. the teams increasingly have to spend more time struggling with the complexity of your software rather than on new features
    • 2. increasing number of bugs found in production
      • directly impact on the number of features that the team can deliver: bug, no matter how small, costs ten times and much to fix in production than it does in development
  • The only way to handle technical debt is to stop creating it, and then pay a little back each iteration
• Scrumble
  • the activity that results from dropping out of the while loop of working software
  • stop piling more features on top of the features that don’t work and fix things so that you can make new things
  • If you can’t ship working software then you need to stop sprinting, Scrumble, and focus on getting your software into a shape that can be delivered in a Sprint
• strategies that can help you both stop creating and start paying back technical-debt
  • Sufficient requirements
    • If your backlog has things in it that are too big or too vague then your team will not really be able to understand them and this, in turn, creates a multiplier for uncertainty
    • Follow the INVEST (Independent, Negotiable, Valued, Estimable, Small, Testable) model for every single thing that you ask the team to deliver
    • This will require you to spend a significant amount of time in refinement
    • Model
      • INVEST for PBIs (Independent, Negotiable, Valued, Estimable, Small, Testable)
  • Developers choose what they can deliver
    • Developers can reject any item on the backlog that they do not understand
    • If we accept that every Developer is trying to do their best to deliver, then the only reason to reject anything would be if an item is too big or does not have enough detail to understand
    • These Backlog Items can be put on the queue for refinement and refined over the next Sprint
  • Definition of Done (DoD)
    • lack of common understanding of DONE
    • Done for Developers should means to complete an item with no further work required to ship
  • Test First
    • Test First practices like TDD or ATDD to help you make sure that not only did your engineers build what they expect, but that you ultimately built what the customer expects
  • Fixed-length iterations
    • If you have variable length iterations you can’t be sure what you can do in a particular timeframe
    • How much decomposition do you need to do to the backlog? How much can the team deliver in a single iteration?
    • Staggered iterations lead to more technical debt and lower-quality software
    • Staggered is called Water-Scrum-fall/ Scrummerfall
  • No separate teams
    • if you have separate teams then why would your Developers, those best placed to fix any problems, care about the problems of other teams
  • Manage dependencies
    • Developers should have all of the skills required to deliver what you want at the quality level that you want. This can be hard for many teams or organizations
    • Product Owners to fight to negotiate over when these things get done
  • Use a modern source control system
    • A modern source control system is more than just code management
• Using a "Technical Debt Register" in Scrum
  • helps to take informed decisions about whether or not to incur debt and when to pay it back
    • p.e. technical debt can be paid off when implementing related backlog items
  • the design decisions which lead to debt can be rationalized, often in terms of probability, impact, and suggested remedy
  • Options to track:
    • RAID log (Risks, Assumptions, Issues, and Dependencies)
    • Information Radiator
      • To Do, In Progress, Done, Escalate, Done (Mitigated or accepted)
  • Managers are thereby encouraged to take an active interest in these registers, as well as impediments on a Scrum board, and to query any unescalated problems that appear to have stalled
• TechnicalDebtQuadrant
  • what kinds of design flaws should or shouldn't be classified as Technical Debt.
  • A good example of this is Uncle Bob's post saying a mess is not a debt. To my mind, the question of whether a design flaw is or isn't debt is the wrong question. Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful in thinking about how to deal with design problems, and how to communicate that thinking
  • I think that the debt metaphor works well in both cases - the difference is in the nature of the debt
    • A mess is a reckless debt which results in crippling interest payments or a long period of paying down the principal
    • The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small - such as if it were in a rarely touched part of the code base
    • So the useful distinction isn't between debt or non-debt, but between prudent and reckless debt
  • Dividing debt into reckless/prudent and deliberate/inadvertent implies a quadrant
    • Deliberated or Inadvertent / Reckless or Prudent
    • Deliberated and Reckless
      • Reckless debt may not be inadvertent. A team may know about good design practices, even be capable of practicing them, but decide to go "quick and dirty" because they think they can't afford the time required to write clean code
      • “We don’t have time for design”
    • Inadvertent and Reckless
      • A team ignorant of design practices is taking on its reckless debt without even realizing how much hock it's getting into
      • “What’s layering?”
    • Deliberated and Prudent
      • The prudent debt is deliberate because the team knows they are taking on a debt, and thus puts some thought as to whether the payoff for an earlier release is greater than the costs of paying it off
      • “We must ship now and deal with the consequences”
    • Inadvertent and Prudent
      • thing sounds odd, I believe that it is - and it's not just common but inevitable for teams that are excellent designers: after, they realize what the design ought to have been
      • It's often the case that it can take a year of programming on a project before you understand what the best design approach should have been
      • the moment you realize what the design should have been, you also realize that you have an inadvertent debt
      • However a problem with using the debt metaphor for this is that I can't conceive of a parallel with taking on a prudent-inadvertent financial debt. As a result I would think it would be difficult to explain to managers why this debt appeared.
      • My view is this kind of debt is inevitable and thus should be expected. Even the best teams will have debt to deal with as a project goes on - even more reason not to recklessly overload it with crummy code
      • “Now we know how we should have done it”