Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

STILL IN DRAFT MODE

Definition

One Gartner analyst defines Technical Debt as "the deviation of an application from non-functional requirements". Wikipedia's definition states "Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer."

The Gartner definition is more complete and possibly more useful; it's not that important why we have technical debt - just that we realize that it exists and can deal with it appropriately. We can look at types of Non-Functional Requirements (NFRs) and imagine how many could result in backlog items (that have nothing to do with a design decision based on expediency):

  • Reliability
  • Security
  • Compatibility
  • Maintainability (Analyzability, Changeability, Testability) 
  • Usability
  • Portability
  • Efficiency
  • Functionality
  • Performance
  • Stability

It's easy to understand how scoring lowly on these items would be a bad thing - and constitute "debt" that needed to be dealt with. However, a lot of these are hard to measure and quantify. For example, what are our requirements for maintainability? Or Efficiency? Or Stability? Clearly, there is a point in which we'd say things are unacceptable; if it took 3 months to fix a bug, the application is not maintainable enough. If it took 17 high powered servers to host 1 user, the application isn't efficient enough. However, when does Maintainability or Efficiency become good enough - i.e., good enough that we don't have to do any more work in the short term to improve it? Our experience is that most NFRs are assessed based on gut feel and position relative to extremes, not specific metrics.

We recommend this definition for Technical Debt:

Application characteristics that deviate from non-functional goals which merit work

Tech Council's role

The definition above uses the loose and non-defined term "non-functional goals", mostly because we feel it will be impossible to list all non-functional requirements, and therefore also very hard to list those that are important. Instead, we recommend relying on the judgment of the people who are working on FOLIO to identify when things are deviating too much from what we feel are where we want to be.

Given that identification and assessment of Technical Debt can be subjective, the community needs to anchor its opinion. Given its role in the project, the Tech Council is the best suited to drive the Tech Debt discussions and to highlight to the community when we may be veering off our desired path relative to any NFR. As with other technical related issues, anyone in the project can bring an item to the Tech Council for consideration. 

It's the Tech Council's role to assess Tech Debt and recommend action; it's not solely its role to identify Tech Debt - the rest of the community should raise issues relative to Tech Debt.

Not all Debt need be paid immediately

Another essential part of a conversation about Tech Debt has to do with payment. It's entirely reasonable to carry debt that you know about given certain circumstances. For example, if you know you are going to replace a module or application in a year, naturally you'd not be as concerned with any debt related to that module or application. Likewise, the cost to fix something may outweigh the perceived benefit from having it fixed... so you might want to wait until you get a bigger bang for your buck when addressing the issue(s).

All this to say that addressing the question about when to address Tech Debt is also a subjective one. 

Process

The Tech Council will periodically (at least annually) survey the FOLIO codebase and technical environment (including existing requests and/or JIRA issues) and make recommendations to the Product Council on timetables to remediate items. 


  • No labels