Examples of Technical Debt - Technical Debt Part 2

Road-map

• Understand what technical debt is.
• Examples of technical debt.
• Measuring technical debt.
• Leveraging technical debt.
• Some strategies to prevent technical debt.
• Dealing with technical debt.

Examples of technical debt

Technical debt is applicable whenever there is a trade-off between the requirements for the purpose of immediate gain.

Insufficient documentation

"If it isn't documented it doesn't exist"

If you lost an invoice for a product can you prove the value of the product or even that you bought that product? The answer is no and the same is valid for anything that is a proof of value.
The purpose of documentation is to keep track of everything that defines value within a tech project and as soon as documentation is neglected it becomes increasingly difficult to keep track of that value. Another symptom of lack of documentation is a difficulty in communication between all the stakeholders within the project.

• Business rules aren't documented.
• Decisions and their reasoning aren't documented.
• Changes to project aren't tracked.
• Existing documentation isn't kept up to standard.

Archaic Debt

If you've ever heard of a barn find, started that hobby project that never got finished or found an old thing that you didn't know even existed then you've probably experienced archaic debt.
Archaic debt is what happens when the value of a project can't be realized or when a project that isn't being supported anymore is still running in production.

• Abandoned, deprecated or forgotten projects.
• A project that performs a critical role but can't be maintained or replaced.
• Projects that aren't kept up to date with the latest standards and techniques.
• Unsupported projects that are keeping the company from moving forward
• Decisions aren't reviewed causing older projects to stay alive long past their lifetime.

Architectural debt

The purpose of an architecture is to make sure that a product lives up to its quality attributes and as soon as an architecture isn't able to do this then architectural debt has been introduced.

• Insufficient architectural design and decision making.
• Isolating projects from the context that they have to live in.
• Arbitrary quality attributes are used to design a project.
• Using a pattern or style because it's "hot", but not because it fits the problem.
• As requirements and the nature of the business change the architectures stay the same.

Code debt

Code debt occurs when the maintainability of a code base is sacrificed to achieve other goals, this is more commonly associated with technical debt.

• Code that has turned into a BBOM or Spaghetti code.
• Unreadable code.
• Referenced libraries aren't kept up to date.
• Frameworks aren't kept up to date.
• Code that is lacking in descriptive comments.

Infrastructural debt

For the purpose of this type of debt think about infrastructure as the hardware and software that supports business activities. Infrastructural debt occurs when the infrastructure gets neglected and ignored so that other things can be prioritized, the most common symptom is failing hardware and software that can't support the business processes effectively.

• The use of unsecure protocols
• Making use of proprietary software that isn't being supported anymore.
• Making use of software that is out of date.
• Expecting newer projects to run on older infrastructures.
• Infrastructure that doesn't grow as the business expands.

Cultural debt

After debating with myself for a long time I decided that this is important enough to keep in here.

Cultural debt is when the culture of a company gets neglected ("work hard, play hard" is not a culture it's a death trap), this often leads to venomous working environments.

• Business departments don't share the same vision.
• "Cowboy Culture".
• Business and IT don't speak the same language anymore.
• Junior employees are left to their own devices.
• Doing things the way they have always been done because "that's how we've always done it".