Why does technical debt accrue?
Often professional solution providers come across situations wherein a client approaches with a request to fix specific issues with an existing system. These requests may sound easy, and at least those are the customer's expectations.
What transpired for the client to end up needing external professional help at a stage where they should have been extracting value from the system?
Reasons could be many, but the two most common reasons are:
-
Someone or some team that implemented it is no more available, or
-
The team that developed the system had done it as a side gig along with their primary work and is now unable to spend any additional effort
To understand this better, one needs to understand what motivates someone to do things independently (DIY) instead of engaging with professional partners. It could be:
-
To minimize costs
-
To keep control over the data, or
-
To maintain ownership of any perceived or actual intellectual property associated with the solution, or
-
That not enough research went in to find a suitable or competent long-term partner
-
They underestimated the real effort
In cases where developing software system solutions are not the client's core business, it makes no sense to take a DIY approach. Such initiatives quickly compound into a massive pile of unmanageable code. In other words, the decision to do everything on their own could result in a compounded "technical debt," which becomes cumbersome with the resources available to the client. Technical debt accumulates because of the following:
-
Designing a solution without considering the entire cycle (solution cycle figure below), keeping the customer problem in the context
-
Lack of testing infrastructure or methods to verify before deployment
-
Constantly evolving frameworks and libraries that, if not updated regularly, lead to bugs or broken functionalities
The cost of technical debt X is the difference between the final solution cost (F) and the initial budgeted costs (E). Below is an illustration of technical debt accumulation, which is rework-cost in manufacturing.
Technical Debt Accrual, the Details
At a granular level, it could be broken down with specific constraints associated with each phase. Each phase requires a different combination of experience, skills, and infrastructure to minimise the technical debt. The debt increases at each stage as the rework cost increases significantly over time.
Illustratively,
X = ax0 + bx1 + cx2 + dx3 + ex4 + fx5 + gx6 + hx7
Where,
a, b, c, d, e, f, g, and h are constraints, e.g., skills, test infrastructure, and experience for each stage of the solutions cycle
x0 to 7 are the time-dependent cost estimates for each of those stages
The figure below illustrates a typical solution cycle. A DIY approach would only increase the technical debt, making it critically challenging and expensive to add new features, scale existing solutions to new customers or even sustain existing solutions.
Particularly with the IIoT solutions, the design through the maintenance cycle must be adequately planned and executed to the customer's problems and needs to extract the maximum benefit. Since this involves varying skills, engage professionals rather than take a DIY approach, wherein priorities are often not aligned with the solution's long-term security, stability, and reliability.
The accumulated technical debt leads to:
-
Extra efforts in maintaining or operating the system
-
Living with sub-standard performance as fixing performance issues would require more than the available resources or time
-
Frustrated employees and customers
-
Also, they are unable to catch up with competitors
Through experience, we have realized that taking a DIY approach might be wiser on some occasions but is a massive accumulator of technical debt in most cases. Costs to clear this debt could be far more than the initially anticipated costs.
Connect with us to learn more about what Technical Debt is in the IoT solutions context and how we can be of help to you in minimizing such debt.
