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”: http://alistair.cockburn.us/Shu+Ha+Ri
(2) James Bach, No KPIs: Use Discussion: http://www.satisfice.com/blog/archives/1440