Technical Debt Management

SaschaWildgrube · ‎05-16-2025

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:

A technical debt is identified – either by the development team, a product owner, or any other stakeholder
The technical debt is documented in the application documentation
The technical debt is added to the backlog
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.
The affected application is baselined any number of times with the set switch state
Once appropriate the switch is flipped and the feature becomes visible (or invisible) depending on stakeholder’s decisions
The affected application is again baselined any number of times
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

Louis R Ronzitt · ‎05-16-2025

Great insight! Our understanding is when using ServiceNow, SAM-P, HAM, EA (formerly, APM) and a fully built out CSDM/CDMB, TRM/TPM, etc., we see technical debt as designed and built into the AI Platform indicated below:

Technical Debt: Technical debts are created at two levels if any of the below-mentioned conditions are met (Manage TRM Technical Debt):

a. LEVEL 1:

(1) If a product is associated with a business application but not part of the TRM product list; OR

(2) If a product is associated with a business application and part of the TRM products list has TRM phase's production unapproved.

b. LEVEL 2:

(1) If a product is associated with a business application and part of the TRM products list has TRM phase's production approval, but no associated TRM Product Lifecycles; OR

(2) If a product is associated with a business application and part of the TRM products list has TRM phase with production approval and TRM product lifecycles exist and do not satisfy either of the below-mentioned 2 cases.

c. Cases:

1) CASE1:(If Application Service Software Model record's life cycle full version is not empty) - TRM product lifecycles:

(a) TRM phase with production approval and;

(b) TRM product's TRM phase with production approval and;

(c) Version matching the life cycle full version of the application service software model record and;

(d) Phase start date <= Today's date <=phase end date.

2) CASE2: (If Application Service Software Model record's life cycle full version is empty) - TRM product lifecycle's:

(a) TRM phase with production approved and;

(b) TRM product's TRM phase with production approval and;

(c) Version is/starts with (based on version operator and isSampPluginInstalled) version of the associated software model and;

(d) edition is/starts with (based on edition operator and isSampPluginInstalled) edition of associated software model and;

(e) phase start date <= Today's date <=phase end date.

References: https://www.servicenow.com/docs/bundle/yokohama-application-portfolio-management/page/product/applic...

sivakalagar · ‎05-23-2025

What are the next steps once a Tech Debt is created by the platform? Can someone create a Demand request, or something else, to resolve the identified tech debt?