Debt Factor - Beyond the Technical Debt

Technical debt is inevitable when applying an agile methodology in a changing environment because of the constant introduction of new procedures and techniques. This article defines technical debt, looks at influencing factors, and goes beyond the debt horizon.

Technical debt definition

The word was first used in 2007 by Ward Cunningham, who invented it by linking "technical" debt with "financial" debt. Financial debt is acceptable as long as you remember to pay it back. For technical debt, the same method is effective.

From financial to technical

You can only run a business by using technology in the modern world.

Companies must check their operations and consumer satisfaction using social media and customer networks.

Product owners manage what customers want and choose which releases to put out based on how much value they add or how they affect regulations.

Technical debt is unavoidable and okay because of the things already mentioned, the market's need for faster releases, and the development of new technologies.

A team can be in (technical) debt as long as they pay it back.

From V-model to agile

When teams used the waterfall method, it was easier to set up some gateways to move further in the project.

One good example is when Microsoft released new products after each product was released, and then Service Packs arrived to remedy what consumers needed to remember or notice.

The delivery model has changed, and most infrastructure is now outsourced to the cloud. This outsourcing means there is no longer a need to store stuff in internal data centers.

Organizations need to make changes more if they want to meet customer expectations and keep track of how well they work.

What is beyond the technical debt

It is possible to argue that teams will always be in debt (See the chart below). There are four main types of debt: Pie chart Xita Transparent

People
Business
Technical
Process

Towards an ontology of terms on technical debt, let’s deep dive into each one of the categories:

Architecture: It refers to the inefficiency of the technical framework (e.g., software or infrastructure).
Requirement: "It is the assumption of the developers that goes to production" – Alberto Brandolini. It describes the development team's tasks to meet the business's requirements. The debt can be intentional (e.g., deploying small packages based on features) or by mistake (e.g., human bias).
Infrastructure: Environment to develop, test and deploy to production and perform integration between different architecture components.
Build: It refers to building the artifacts to be delivered to the following environment. (e.g., high dependency).
Code: It relates to a lack of guidelines to develop software code and occasionally causes refactors. (e.g., duplicated code, slow algorithms)
Defect: Known the flaws, and by agreement with the acceptance, it will be fixed in future releases.
Design: Designing solutions without using good principles for development and causing high-coupled systems. (e.g., intense coupling, duplicated code).
Documentation: The most common debt is, documentation is always incomplete or outdated. However, the easiest to be paid.
Skills: This debt is also one of the most common issues in teams and projects. Not the number of people but also related to the lack of skills of a few members. (e.g., staff shortage).
Social: As people are constantly relying on interacting with machines, they are looking to themselves to find the solution to the problem. However, when collaboration is required in a dynamic environment, sharing ideas and different perspectives on the problem and/or solution is needed.
Process: It refers to the inefficient or non-existing processes to support the teams. (e.g., procedures to define the LCM).
Service: Creating and/or modifying a service or API to expose a particular function to achieve delivery of a value demand by a counterpart. (e.g., selection/replacement of APIs or web services).
Test automation: The development of automation for developed testing artifacts, supporting continuous integration.
Testing: The number of test activities to be executed or the number of functionalities covered by the test scenarios. (e.g., low coverage)

Aligning the different debts

Not only is it the job of the product owner and the domain team, but the company must also emphasize the strategic growth of each employee.

The McKinsey three horizons approach can help ensure that learning and development happen in the short, medium, and long term. And it can also help find out what skills will speed up time-to-market.

With the growth model, the company may provide financial resources for the team and employee development.

Graph 1: Three horizons model Line graph Xita Transparant

Horizon 1: Focus on improvement or increments on what the organization already has;

Horizon 2: Focus on adapting or changing business models that work well in other industries;

Horizon 3: Disruptive architecture/model change for B2B markets by the incremental process;

The dark side of the moon

Dark debt is related to the consequences caused by the combination of new events or factors that might create ‘wicked’ problems. This topic relies on meta-models and human biases and would deviate from this article’s subject.

The term "dark debt" refers to the costs that arise when new events or causes combine to produce "wicked" difficulties.

This is off-topic for this article because it involves meta-models and the inherent biases of humans.

Dark debt is a form of technical debt that is not visible until it causes failure. Unlike technical debt, dark debt is not limited to code. It can happen anywhere and plays out across any complex system.

Dark debt appears as anomalies, unlike technical debt, which may be refactored.

Dark Debt causes unexpected system breakdowns and abnormalities. You can find Dark debts by testing how well the system can handle failures while still providing acceptable service levels. You can learn about your dark debt early by putting dangerous things into the system, like a failure.

Anticipate when the debt may become problematic and implement measures to cut it. One of the best ways to avoid the harmful effects of technical debt is to keep an eye out for signs that a reasonable amount of debt is moving into the realm of irresponsibility.

Taking shortcuts in your code to get your product out the door faster is an example of technical debt.

Technical debt can also slow digital growth, as having a lot of financial debt can limit a person or business's financial options.

High levels of technical debt, like credit card debt, can cause a downward spiral of failed attempts to modernize, leading to even more tech debt.

Blaming for delays on technical debt makes it harder to see what's going on and keeps your cross-functional teammates in the dark. You have to poke and prod at your designs through production to find dark debt before it causes a costly disruption on its terms and schedule. Chaos engineering and incident learning are popular in the business because of this.

Conclusion:

Organizations, teams, and individuals must work together to deal with growth strategy and technical debt and be in sync with the system.

SRE, DevOps, and platform engineering offer the following to help with context:

How to make a scalable engineering process by learning from mistakes and improving the results
How to create an end-to-end culture so teams can take ownership of the products and services they deliver
Use the best methods for making software and pay attention to the product