A technical debt is any state in a software module that has a negative impact on its maintainability and requires future work but does not prevent production use.

What exactly should be considered as technical debt is certainly subjective. Here are some examples that can be considered as technical debt:

• Dependencies to outdated or even deprecated libraries or components
• Duplicate code
• Dead or unreachable code
• Incorrect or misleading names of database entities (tables) or fields
• API naming inconsistencies (e.g., functions “GetInstanceURL()” vs. function “GetRecordUrl()” – note the different spelling of “URL” vs. “Url”)
• Non-compliance with the coding guideline
• Insufficient or missing documentation
• Insufficient test coverage
• Deprecated features
• Unfinished work
• Fully operational features not yet to be exposed to users

For disambiguation: Sometimes the term technical debt is used in publications to criticize excessive customization or deviation from OOTB configuration. The definition used in this article is more specific (and less judgmental).

A lot has been said and written about the long-term costs and effects of technical debt. For the context of this process, there are two main take-aways:

• Anything that is identified as a technical debt must be represented by a backlog item and treated like any other item that represents future work - e.g., a business requirement – apply the boy scout rule – not all technical debt is known (or even considered as such) when it appears – the whole team should always document technical debt when they see it
• Technical debt should be documented as part of the application documentation which ideally is part of the application itself (e.g., as a UI page).

From the above list there are two special forms of technical debt: Unfinished work and features not yet to be exposed to users. One might argue that these have no negative impact on the long run. One may say: the opposite is true. But only after a feature is completed, or a completed feature is finally exposed to users, will it generate value to the business, and not just incur costs.

However, in the context of this process, it is pragmatic to treat such cases as technical debt, because they need to be managed in the same way. Unfinished work obviously requires future work and a completed feature that does not provide value to users still needs to be maintained until it is released – which again may imply additional costs – although hopefully not for a very long time.

The cases of unfinished work and completed features not yet to be exposed are specifically important. The guidance in this document is to commit all work into the development branch, as early and as often as possible. This leads to a state in which the development branch may contain unfinished code or application files at the time of the next version baseline.

My advice is not to use selective commits or feature branches - so we need a technique to manage unfinished work.

The following outlines the life cycle of technical debt:

1. A technical debt is identified – either by the development team, a product owner, or any other stakeholder
2. The technical debt is documented in the application documentation
3. The technical debt is added to the backlog
4. If applicable a switch is introduced to render parts of the application inactive or at least invisible to users. The switch is set to whatever is appropriate at the time.
5. The affected application is baselined any number of times with the set switch state
6. Once appropriate the switch is flipped and the feature becomes visible (or invisible) depending on stakeholder’s decisions
7. The affected application is again baselined any number of times
8. The technical debt is resolved, the switch is (and eventually the feature) is removed from the application

To perform Technical Debt Management on a day-to-day basis, the platform must be extended with the following capabilities:

• Document technical debt of an application in a way that these records are part of the application so that they are also stored in the application’s source code repository
• The technical debt records must be stored in a way that they can be retrieved and processed from a source code repository
• Documentation on technical debt can be generated automatically based on these records
• Each technical debt record has a switch that can be turned on and off
• A function is available to request the state of a technical debt switch – to control application behavior depending on the switch state

The latter two requirements are crucial for cases of unfinished work and features not yet to be released to production.

These requirements are not met by the ServiceNow platform OOTB – hence these additional capabilities must be implemented.

The open-source application “DevTools” supports these capabilities:

https://www.wildgrube.com/servicenow-devtools

Read the full story:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf