STILL IN DRAFT MODE
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 really 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):
- Maintainability (Analyzability, Changeability,Testability)
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 unnacceptable; 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. But 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 gut feel and position relative to extremes, not specific metrics.
We recommend that we define Technical Debt as:
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 actually important. Instead we recommend relying on the judgement 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 needs to be paid immediately
Another important part of a conversation about Tech Debt has to do with payment. It's quite 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.
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.