Challenges with the Concept of a Technical Debt
When I first went through the PEAF and read a bit more about the concept of a technical debt, I was quite anxious about trying it out. And not long after that I even got a chance to mess around the topic a bit.
I have made some observations which I did not find addressed anywhere else, so I am raising these topics here and I wonder how you did or would tackle those.
Before that I have to put down some assumptions up front so that we are on the same page. In the company there exists a sort of TO-BE architecture. It is quite vague and not all that clear, heavily misinterpreted, but it’s there and awareness is there as well. The debt gets measured based on non-compliance to the TO-BE architecture. So it is an indication about how much we deviate from the envisioned target. We try to estimate the debt as potential costs of needed remedy actions that we will have to take in the future to make the solution compliant. It is not all that important for the rest of the article how we describe the target (by system landscape, guiding principles, directives or something else). And at last, the company is very strongly driven by time-to-market, which might be one of the reasons why high level management is even aware of the term “debt”.
And here come the observations:
TO-BE Architecture Stability
Measuring of the debt depends heavily on the definition of the target state. Should this definition change, the measured technical debt value becomes obsolete and there’s hardly any further interpretation towards the new target possible. (Otherwise, all solutions from the past would have to be re-evaluated for compliance to the new TO-BE state, which is – I dare to say – impossible). The bottom line is that with change to the TO-BE state the debt measuring would have to be restarted from the ground zero. This implies that TO-BE architecture must be robust enough to sustain and absorb potential future changes in tactics/strategy, technology, processes and organization. This might be quite tough to achieve.
Responsibility for the Technical Debt
Although the term is an indication of some kind of a technical flaw or drawback related to the envisioned target, it must not be understood as incapability of IT to deliver appropriate compliant solution. The debt gets created by (in my experience usually) business decisions (to be more exact – by budget owners) so it is business (or a budget owner) who willingly and intentionally accepts the debt. Responsibility for the consequences must be then placed there as well.
Of course, I do bear in mind that taking a debt is not bad by principle. It is only very risky, when it is hidden.
Responsibility for the TO-BE Architecture
It should be clearly understood that technical debt – if measured transparently – is intentional and accepted by business. Hand in hand must also go the acceptance of the target architecture by business, as it is the main measure for compliance and calculation of the debt. It is of an utmost importance that business understands and commits to the envisioned target state as the goal that is to be reached by the company. Challenging, right?
The fact that project is incurring a technical debt can cause demotivation and frustration in the team (assuming there are smart people in the project and they would prefer to do the thing “right”), lack of openness, sabotage of the project and other social changes. It is important to communicate clearly the goals and interpretation of the debt by management. By no means should the level of debt be reflected in KPIs of performance of the technical team.
Debt Created Outside of Projects
Challenging can be also tracking of a debt that gets created outside of projects. This might be specific to companies I worked in, but there’s quite a lot going on behind the scenes of IT. Whether we call it “daily business” or “innovation”, there a chance that some debt gets created. Why is that? Well, because in IT there’s always some hunger for creativity. And developing and maintaining business applications with best practices at hand and tools ready and frameworks out there is not that much fun. So new frameworks emerge, without which the application “just could not be built”, and we add bits here and there, and use newer framework each and every time we develop a piece of software. Or just be calling some changes “maintenance” we pollute the system with a loooot of stuff.
Dealing with Past Hidden Debt
Here the question is quite simple: what to do with a debt that was taken before the company started measuring it? Would you just ignore it and start from zero? Would you try to capture such a debt whenever you come across non-compliance in the IT landscape? I don’t like any of these two really. In the former case any venture that would address past faults would not be perceived as a remedial action. In the later case, some corps might be uncovered which can cause lots of finger-pointing, back-talking, eventually not helping at all.
Paying-off the Debt
One of the bigger problems I have with the technical debt as analogy to a real life is that it is not straightforward how to pay off a technical debt or even if it is not always clear if it is paid off fully. It’s like having really ugly weed in the backyard and deciding whether to deal with it when you see the first plant, or letting it be until its spread everywhere. Even when you think you got rid of it, it pops up somewhere again. In IT this is quite simple. You sacrifice compliance once, but then you built other thing on top, around, under, and it all depends on sub-optimal architecture already. Is it even possible to “heal” it? Also, would it count as paying-off the debt, if we just heal symptoms, not the cause? As an example take say bad quality of data. Do we Is it a remedy when we built fancy expensive master data management system to deal with the mess in the back?
More I write about it more questions I have open. Have you ever experimented with the topic in your business? Have you dealt with “interest rate” on such a debt? Or was it enough to stay very basic and only show, in how many cases a decision was made in favor of compliant solution? I am interested in your experience.