Shallow and risky view of technical debt

I spoke about technical debt in previous posts here, here, here and here .

Once again I have noticed, how the shallow view of (what is nowadays called) technical debt can ignore risky situations. Risky because some people can ignore certain things which might be problematic. I am referring to some managers, but there are also some “shallow” developers who have an apparent good discourse but nothing else. They think that a number (like the one offered by Sonar for example) is enough to provide them comfort when handling/managing/running/reporting on a project, when actually that number should not be interpreted so inclusively.

So, here are some premises:

  1. I said above “nowadays” because I noticed a difference between what technical debt meant initially, in 1992, and what technical debt is today, for a lot of people.

So, the original meaning of the message intended to be transmitted, was that technical debt is about the misalignment between the current code and known requirements[1]  – I think here might also fit in what Jim Coplien said: that maybe it wasn’t the requirements that have changed, but our understanding of the requirements were the ones that changed[2]. Ward Cunningham actually made in 2009 a new video regarding technical debt in which he “reflects on the history, motivation and common misunderstanding of the “debt metaphor” as motivation for refactoring.”[3]

What technical debt means now: messy code.

I think that, maybe, it’s ok for the original message/meaning to be known in the sense that might bring a new nonconscious perspective. The perspective that can ultimately help, by shaking the bases itself, to a better end.

  1. Martin Fowler tries to depict technical debt in an interesting way by using the quadrant[4]. This part is important because it shows us some dimensions of this concept that are not covered in our analysis/actions/approaches and are not so easily summarized into a number.
  1. Static code analysis tools do not give us straight clear information regarding SOLID principles, or  “4 rules of simple design”, or lean architecture[5]. For example:
  • Regarding SOLID: SRP can be deduced by looking at coupling and cyclomatic complexity. DIP can be deduced by looking at cyclomatic complexity. ISP by looking at empty methods, long methods and cyclomatic complexity. LSP…nothing [6].
  • “4 rules of simple design”: “Reveals intention” is about human judgment [6].

“No duplication” it might seem easy, but is not quite like this; I agree that there are good tools to measure this, but it doesn’t mean that all duplication is bad at a certain moment. I have observed that is not about a number, but in fact it’s about several numbers because it depends on the minimum number of block lines considered when making the comparison(try to run duplication analysis by changing the minimum block size).

  • “Lean architecture”: A special context might be built to make lean architecture at its place, but even if we do this, anomalies can / will still be introduced. I do not think it’s that easy to measure via static code analysis tools;
  1. I understand the need for tool(s) and I’m all for using tools – I’ve just recently developed two – because after all we’re homo faber. But besides that, we are also homo narrans, and these are axes among the atlas in what really makes us homo sapiens[7].


– It is usually said, in my circles, to try/justify a new idea(bad or good) by saying: ”At least now we have something, before we had nothing”. The premises mentioned above are a way to contribute more to that “at least now we have something”, now I would say “we have a little more”;

– The following question often arises, in my circles: “What can we do better?”. The intent of the mentioned premises is the belief that by exposing them we will be in a much better position to expose/treat/manage/act/test/tackle what is technical debt;

– It’s good that we have Sonar, NDepend, … I do not deny their usefulness. But we have to understand their limited applicability;

– I understand that there is a need to show to our customers, if needed and applicable, that we handle/manage/tackle technical debt. Let’s say that it’s like a sale/marketing that we have to do, if I can say so. But at the same time, it should not be mistakenly believed that those numbers will save a project or even indicate reality. That’s why it means nothing to me to hear someone say that “the technical debt is just 1/2/3/…days to work on”;

Small Note: More technologies, especially those based on JavaScript, do not yet have the tools of code analysis as pertinent as possible. Javascript is an OOP language, for example. It’s great that there are tools like JSLint or something to find duplicates, but it does not quite indicate the cruel reality of a situation(I am thinking of design, oop, architecture when I say this).

– I do not think that technical debt can be described by just a simple number, just look at the dimensions exposed by Martin Fowler. So, we might have a management problem which should not be handled only via Sonar or alike. From those dimensions I think we might spot some social things;

– I do not believe it’s enough to establish together with the client the rules for Sonar or alike, only use them and that’s it; we have to go beyond;

– We need seniority and human judgment, a tool cannot offer this. It can help, but it cannot substitute them completely;

[1] Michael “Doc” Norton, “Technical Debt”,

[2] I am still looking for the reference…

[3] Ward Cunningham, “Debt Metaphor”,

[4] Martin Fowler, “Technical Debt Quadrant”,

[5] Jim Coplien, “Lean Architecture”,

[6] Michael “Doc” Norton, “Tracking and Managing”,

[7] Dave Snowden, “Of material objects” ,

Managing technical debt discussion

Shu(1): We found a way to manage technical debt on the projects. I’m curious what you think about it.

Ri: Tell me more. How did this topic arise? Why was your team affected by this?

Shu: Well, it was a top down decision. So we have to manage it somehow. And for doing so we have to see where we are.

Ri: So you don’t know why. The fact that it’s a top down decision doesn’t mean you know the answer to the “why” question. So you are affected because you all have to do it. Hmm…ok. Why do you say “we have to see where we are”?

Shu: By “we have to see where we are” I mean that we need some numbers, like those provided by Sonar.

Ri: Numbers? Don’t you already know how your project stands from a technical point of view?

Shu: Hmm…I don’t understand what you’re trying to say. This is what I was told to do.

Ri: Don’t you participate actively in the day to day work of the project? Aren’t you capable to articulate some aspects?

Shu: Well…yes.

Ri: So why are you acting childishly?

Shu: Childishly?

Ri: Yes. Why do you think complex and complicated stuff can be reduced to numbers? I understand that parents need to make things simple for their kids but you are an adult … you should be able to handle complexity and complicated stuff. (2)

Shu: Why do you think numbers are not ok?

Ri: I didn’t say that. I said that it’s not ok to reduce such an important topic to a simple number.

Shu: Well… then how do you know you are ok from a technical point of view?

Ri: Is technical debt actually a technical problem?

Shu: Ha?

Ri: Ok. Let’s take an example regarding numbers. You have a module 1 which was not modified for years, some of the code is actually generated and it has lots of warnings. What do you do? What do those numbers regarding the module 1 tell you, compared with another module 2 which was modified 5 times in the last 2 sprints? In the end, Sonar tells you that you have 500 days of technical debt. So what will you do about that?

Shu: I will want everything to be cleaned up.

Ri: Why?

Shu: Because clean code matters.

Ri: Don’t deviate. Don’t tell me platitudes. What we are talking about here is how you interpret those numbers and how your actions are guided by them.

Shu: I think that, maybe, we should handle module 2 issues first, and then module 1 issues.

Ri: So what do those 500 days mean?

Shu: I don’t know.

Ri: Why not? It’s a clear number written there….

Shu: It seems that days representing module 2 are more important than days representing module 1.

Ri: Will it always be like this?

Shu: Hmmm….Now that you ask, I am tempted to say: no.

Ri: So, let’s go back to the question: what do those 500 days means?

Shu: I don’t know. At first sight it seemed clear but now it doesn’t anymore.

Ri: Good, you begun to think a little bit. So do you think that by seeing those numbers you can know where you are?

Shu: Nope.

Ri: Why not? At least now you have something. Initially, it seemed, you had nothing.

Shu: Hmmm…actually I did had something….by participating in the work that was done, I saw: the code, automated checks, professionalism of the team members, how prepared the team members are, behaviour of writing code of the team members, bugs, issues, problems, testing. So in a way, tools like Sonar help a little bit by providing a perspective, but to say that they are the key point in managing technical debt is not ok. So tools like Sonar continue the list I mentioned above?

Ri: There is one point I wish you would have mentioned. How do you know, by looking at the code,  what problems it had?

Shu: I have to see the history of the code. A lot of information lies in source control. Information which has to be analyzed and interpreted according to context.

Ri: So technical debt is only a technical problem which can be tracked/simplified by some numbers shown to the upper management..numbers which occasionally are stripped out from context?

Shu: Nope… A lot of discussions have to take place, based on the unfolded details.(2)

Ri: Let me come back to the beginning, and ask: why did top management impose this?

Shu: Hmm. I think I know the answer but I can’t articulate it.

Ri: You just mentioned a long list of dimensions when managing technical debt. Are all people managing the projects aware of those dimensions?

Shu: No.

Ri: What should top management do in this case?

Shu: Impose, so things won’t go in the wrong direction.

Ri: Yes, but why?

Shu: Lack of trust? I believe they thought that having Sonar as a common denominator for all projects was a way to at least control the complexity and mediocracy of the people managing the projects. Mediocrity which in the end affects the dynamics of the project a lot, and which creates a space also for technical problems to flourish.

(1) Alistair Cockburn, “Shu Ha Ri”:

(2) James Bach, No KPIs: Use Discussion:

Regarding Technical Debt Quadrants

I like the way Martin Fowler(1) tried to classify Technical Debt. I think it was a way to show,in a simple not simplistic way, how to grasp the complex nature of what technical debt actually means and how to handle it. I intentionally said complex not complicated.

So, technical debt might appear easier to grasp ( especially due to code analysis tools) but maybe it’s not like that. It seems that we have to rely on the sapience of developers, and I would say testers(2) as well, to take care of the code.

Below are some short thoughts regarding quadrant elements:

–  reckless vs prudent for inadvertent: I connected it with the training/qualification of developer(s);

– reckless inadvertent: it seems that (some) basic notions of oop/design/architecture/… are missing;

– prudent inadvertent: we might deal with good developer(s) who had an “aha” moment. In this case, the simple fact that they realized something is a good thing, it’s a sign of progress;

– reckless deliberate: it’s a clear intention for “quick and dirty”. This might be ok in a certain moment because this decision is intentional and fully aware of the context. And it is known that it will be taken care of.

But I usually see this “quick and dirty” solutions from so called senior developers who are unprofessional. For example, these unprofessional devs:

  • preach that they want clean code and assure their team members that they want to do it, but behind closed doors they are doing actions( technical work) to impede this;
  • are happy to do some small checks/verifications/investigations which requires no management approval but they ask for time allocation and for the management to agree. And they do this because they know they can sabotage the things so that in the end to do the “quick and dirty” way.

– Prudent deliberate, if applied ok (not by so called seniors mentioned above), might be a sign of holistic thought. It makes me think of the mantra: “First make it work, then make it right, then make it small and fast.”(3)

So, things are not so simple when speaking about technical debt. For those that are interested only in numbers I have a question: How many developers do you know that connect neuroscience, cognitive psychology, complexity theory and forensic psychology with how code is written?

(1) Martin Fowler,   Technical Debt Quadrant:

(2) Context Driven Testing:

(3) Robert C. Martin, Test First:

Faking the reduction of technical debt

I spoke before about multidimensionality of technical debt.

Unfortunately, sometimes, “Reducing Technical Debt” is used as dust in the eyes. It’s not that obvious when we also use tools for “Reducing Technical Debt”(like Sonar, Ndepend,….). I mean who can contradict the efforts in reducing the technical debt when the people doing it also use tools and can show some numbers? If some non-sense warnings are also solved to decrease the numbers…wow.. they are really attacking the technical debt.

Maybe the real test in showing that work is being done  in  reducing the technical debt, is when some important technical problem must be solved. But because of strange forces it doesn’t get solved. I’m speaking about that kind of problem which will help in lots of directions( including financially!!). That kind of problem which is a pain for years and years but it is never touched.

Why won’t this problem be solved? Probably because the current situation is more comfortable for the people that should take care of it. The present situation  is easier, the status quo is known, as well as how to react in it. Perhaps the desire to reduce the technical debt isn’t real in the first place, and the work is done just for show, just to follow the trend. Or maybe because we simply don’t have too many scrum masters/PO’s/managers that actually understand how software is build…..

Some perverse/strange/sick situations arise when dealing with reducing the technical debt, especially when this is imposed. These situations on the surface might seem to be ok but below the surface might be a total mess. A mess that’s hard to detect if you’re not looking at the code, but instead, just analyzing some numbers generated by the tools.

Technical Debt in relation to Business Features/Roadmap

The technical debt subject, especially in relation to business features/roadmap, continues to pop up. Sometimes I have the feeling that certain people (especially managers) lack some understanding of certain dimensions which should probably be considered in regard to this subject. So, below, there are some points to consider when thinking about technical debt concept and also its relationship with business features/roadmap:

  1. Dualism: There is a strong emphasis on a dualistic way of approaching things. In a way it’s understandable, it goes back to cartesian dualism. Dualistic categories in which one side is right and the other, probably wrong. In this case business and technical debt are thought of as being dual. Technical debt, if approached with pragmatism, helps improve the cycle time; but pragmatism requires knowledge. So actually if we speak with Business People/PO/…, they should think in terms of “business features” and “business cycle time.”(1)

Note: I have said knowledge. With technical debt, unfortunately, the trending words are now tool names (like Sonar). The tools are good, but they must be used wisely.

2.”Quality is a statement about some person(s)”(2):

Let’s not forget about the fact that the decisions of PO’s/SM’s/Architects/Developers might appear rational but in fact those decisions are emotional and political. For example:

– a PO might be too afraid to impact the release;

– the work of an architect might be put away or delayed or he/she has to have an argue with someone – which is not in his/her interest;

– A developer may not want stress. It has other priorities/things to do;

All above examples might be understandable or not, it depends on the context. Still “quality is a statement about some person(s)” .

  1. Technical Debt:

I think this is such a misunderstood concept. This word is used often and connected suddenly to tools. But tools only assist, and those tools should be used in a sapient way(3). There is much more to technical debt and it’s a sad thing that I see it  trivialized and bastardized. So when I think of technical debt I think of: prudent deliberate technical debt, reckless deliberate technical debt, reckless inadvertent technical debt, prudent inadvertent technical debt and the history of this concept.(4)(5)(6)

  1. Wrong metaphor regarding IT and code:

We think that when we apply measurements on the code, that it’s the same as in engineering. Well it’s not quite like this. When civil engineers do the measurements and planning, there is a clear way of what will be constructed, no false positives(7). It’s a complicated thing, meaning that there is a clear way between causes and effects. In software it’s not like that. What we have are only fuzzy things. Ok,  we’ll repair all the warnings and errors spotted by the code analysis tools (Eg: FxCop/Code Analysis, Ndepend, Puma, Sonar, …). Then what? Will the software be ok? No, we do not have the same certainty as in engineering. There are lots of false positives and if the approach is not made carefully, holistic view might be lost.

So what’s the metaphor? Maybe it’s biology, ecology, medicine.

Note: Tools are ok. They help and extend human capabilities, but they are not a replacement for human judgment.

How can I show that the technical aspects are ok on the project? When I hear this question, at first glance, I do not have technicality in my head. I try to see the holistic view: social part (by the way architecture has a social component), release time, impact on testing, lost time, features delivered, responding fast enough to changes, capable to deliver innovative things fast enough that not even users know how to articulate or need…

So: Technical Debt or Business Feature/Roadmap? When this question is raised and a decision has to be made, for me it’s a heuristic that things are not considered, not even in the last responsible moment. Things didn’t happen in isolation and this means it’s a good moment to think about risks.(8)(9)

(1) Jim Highsmith, “Features or Quality? Selling Software Excellence to Business Partners”:

(2) Jerry Weinberg, “Agile and the definition of quality”:

(3) James Bach, Sapient Processes:

(4) “Ward Explains Debt Metaphor”:

(5) Martin Fowler, “TechnicalDebtQuadrant”:

(6) Michael “Doc” Norton, “Technical Debt”:

(7)  Mark Seemann, Human Code:

(8) Michael “Doc” Norton, a phrase regarding technical debt:

(9) Cory Flanigan post on LinkedIn and comment from  Michael “Doc” Norton: