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:
- 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)” .
- 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)
- 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”: http://jimhighsmith.com/features-or-quality-selling-software-excellence-to-business-partners/
(2) Jerry Weinberg, “Agile and the definition of quality”: http://secretsofconsulting.blogspot.ro/2012/09/agile-and-definition-of-quality.html?m=1
(3) James Bach, Sapient Processes: http://www.satisfice.com/blog/archives/99
(4) “Ward Explains Debt Metaphor”: http://wiki.c2.com/?WardExplainsDebtMetaphor
(5) Martin Fowler, “TechnicalDebtQuadrant”: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
(6) Michael “Doc” Norton, “Technical Debt”: https://cleancoders.com/videos/technical-debt
(7) Mark Seemann, Human Code: https://cleancoders.com/episode/humane-code-real-episode-1
(8) Michael “Doc” Norton, a phrase regarding technical debt: https://www.linkedin.com/feed/update/urn:li:activity:6338750195731353600
(9) Cory Flanigan post on LinkedIn and comment from Michael “Doc” Norton: https://www.linkedin.com/feed/update/urn:li:activity:6339019436988727296