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

Version 1 Next »



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. We can look at types of Non-Functional Requirements (NFRs):

  • Reliability
  • Security
  • Compatibility
  • Maintainability (Analyzability, Changeability,Testability) 
  • Usability
  • Portability
  • Efficiency
  • 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 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

Technical Debt is Subjective

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. 

Here are a couple of concrete examples of Technical Debt:

External Dependency 

  • No labels