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:
- 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.
- 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.
- 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;
- 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].
Conclusions:
– 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”, https://cleancoders.com/episode/technical-debt-episode-1/show
[2] I am still looking for the reference…
[3] Ward Cunningham, “Debt Metaphor”, https://www.youtube.com/watch?v=pqeJFYwnkjE
[4] Martin Fowler, “Technical Debt Quadrant”, https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
[5] Jim Coplien, “Lean Architecture”, https://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208
[6] Michael “Doc” Norton, “Tracking and Managing”, https://cleancoders.com/episode/technical-debt-episode-2/show
[7] Dave Snowden, “Of material objects” , http://cognitive-edge.com/blog/of-material-objects/