How Architects Can Help Reduce Technical Debt

Wikipedia: a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. As with monetary debt, if technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes.

The widely held view is that technical debt (tech debt) is bad and development teams should strive to eliminate it. And the definition is that tech debt is due to poor decisions. But I, as always, like to suggest a slightly contrarian view.

Tech debt is an inevitability of systems that are agile and change to support business needs that are constantly evolving. Every organization is accelerating its digital transformation plans to support hybrid working. That has had a profound impact on the systems that support the business, and the pace of those changes often means that there is tech debt. At the same time, Salesforce is investing heavily in the platform so customer functionality that was developed in-house may now be a core platform feature.

Firstly, not all tech debt is bad. Some tech debt clearly delays projects either by making it harder to deliver changes, or it needs to be removed before new projects can be implemented and that takes time. But other tech debt is ok. If it is in an area of the org that rarely changes, it has limited impact.

If it ain’t broke, don’t fix it

The real issue is that in many (most?) orgs the levels and hotspots of tech debt are not understood. This makes it very difficult to scope and estimate changes with any level of confidence. The project scope changes as they encounter tech debt which delays their releases. Or there is a separate tech debt clean-up project which stops all future changes until it is complete.

We’ve come across a couple of clients recently who have put a freeze on all and any changes for over 6 months because they need to get an understanding of their org and clean up the tech debt. Incidentally, without the insights that the org impact and dependency analysis that Change Intelligence Platforms provide, these clients might have simply thrown the org away and started again.

Not all technical debt is equal

There are several ways that tech debt makes its way into orgs. They are listed below, and you’ll probably recognize some of them. The first thing to note is that not all tech debt is due to poor design or cutting corners as the wiki entry suggests.

• Change or outdated design: tech debt is when the business needs have changed and therefore functionality is no longer needed, but safer to leave the functionality in.
• New release: tech debt occurs when new platform functionality supersedes features from prior releases or custom development. For example: PBW to Flow
• Deliberate: tech debt is when a conscious decision is made to speed up development with the clear view that it will be more costly in the long term, but this is considered the right path
• Accidental: tech debt accumulates when shortcuts are taken for any number of reasons — most commonly because of time constraints or multiple parallel work streams.
• Bolt on: tech debt happens when a specific functionality keeps getting extended in increments and “bolted on” to keep it working, rather than rebuilding it properly.

So how should we evaluate tech debt?

Tech debt is called “debt” because it needs to be repaid. So if we look at debt and the different levels of interest rates we pay on it we can see how it changes our behavior.

High impact — Credit card: 29% ARR

• Impact on current change projects
• Increase in development times
• Delay whilst a project refactors the debt
• Affects Salesforce performance
• Surprises/conflict cause release rollbacks

Medium impact — Car loan: 5% ARR

• Impact on future projects scheduled
• Increase in development times
• Delay whilst a project refactors the debt

Low impact — Borrowing from family: 0.0% ARR

• Limited or no changes project
• No impact

How to reduce tech debt

First, you need to understand the org configuration to be able to categorize the tech debt. But understanding your org is fundamental to reducing the risk of any project. Using the APIs it is possible to build a metadata dictionary and then analyze it to create a map of the dependencies and field population. Update it nightly to ensure that you’re working with the most up-to-date information.

You need a complete picture of the org metadata and analysis. A partial view of the metadata is not good enough to make solid decisions, so you won’t be able to rely on an out-of-date spreadsheet dump of the org metadata, a list of some metadata dependencies using DAPI or a list of the fields with no data.

Armed with an understanding of the project scope and the org complexity in the area the project touches, you can evaluate the level of tech debt and the strategy for reducing it.

Below is the suggested approach taking into account the type of debt and the level of impact

Architects can impact technical debt

There are several ways architects can reduce the build-up of technical debt and also reduce existing debt. Here are some of them.

Ask the right questions:

Teamed up with the business analysts, architects need to question every requirement, every change, and every specification. They need to ensure that the developers are “building the right thing”. There are clear benefits in reduced rework and improved adoption. But there is also the issue that every change that is made is more metadata that is difficult to delete with confidence.

Architects need a good understanding of the implementation lifecycle and the business analysis tools and techniques such as UPN process mapping and facilitating live user workshops.

Great data design:

Ensure that the data model has been designed with performance, scalability, security, integration, and agility in mind. This may take time and the need to balance short and long-term objectives. However, we see orgs that have made snap decisions on data design which have proven to be prohibitively expensive to fix or even fatal (throw the org away and start again). For example, enabling person accounts, 40 look-up fields on an object, using a record type for every new client.

Good ERD modeling analysis is a core skill for an architect and there are training courses and a Salesforce Diagram standard.

Write it down:

The first, and easiest approach is to provide good documentation. Poor documentation is the #1 cause of tech debt. If the metadata does not have why it was created, where it is used and who are the stakeholders, then it is very difficult to change, deprecate or delete. So instead new metadata is added, often which is very similar to the existing metadata. Until it goes on, release after release, year after year.

There is hope. Salesforce has released the Salesforce Diagrams standard for ERD, System Landscape, Integration Layer, and User Provisioning and Deprovisioning Flow Diagrams. This complements the UPN standard for process mapping and also requirements and user stories.

Final word

Many (or most) orgs have high levels of tech debt that limit agility. But only with complete org understanding and analysis can a strategy be developed to pay down the tech debt focusing on those with the highest interest rates. But the architect can also influence tech debt in the design decisions they make and the documentation that they create.