Following a link from this Martin Fowler’s post I was pleased to find this great piece by Henrik Kniberg.
In that post he talks about the mess we sometimes create while coding our way through an issue.
He calls it “Good Technical Debt” and explains us the crucial role it plays in helping us being in a “flow state” in a moment in which distractions would be detrimental to our reasoning. Moreover these temporary deferring of the “cleaning up” helps us making connections too and avoids us to incur in premature convergence.
I found his kitchen metaphor really fitting as far as flow and time optimization is concerned and I encourage you to read the post to understand what I’m referring to.
I would like to strongly advocate 1 of the details of that post and to raise 1 doubt regarding another part of the same post.
Who wants to clean, after all?
I believe that the following sentence is too often neglected: basically, a software developer’s work is more often than not a creative one.
And, if she needs to generate and connect ideas to find the right one, a developer needs to relax the constraints and feel free to act. Additionally she needs to keep all the ideas as much as she can during the discovery phase thus avoiding to delete precious ones too early.
All well and good but what makes the whole post stand out from the crowd is the author providing us his own precise idea of how much time such “good tech debt” can survive:
“My experience is that, in software, the “good mess” is only good up to a few days”
I want to underline how short this period of time is. This means that cleaning the mess is part of doing every single thing, not something we should reserve buffer time for.
In my experience one of the reasons for tech debt stacking relies in the people failing to agree on how much time one can survive without cleaning his own code.
To me this is really important to underline and to keep in mind. We need to agree with ourselves and with our team a strict and certain time box for the creative mess we produce.
If we fail in doing it we are prone to “Hyperbolic discounting” in the form of self-indulgence with the quality of what we produce. We end up thinking: “…after all, these little tricky details are not so bad if compared with the great solution I created. It’s not worth to spend time now cleaning it, while I can move to bravely solve another tough issue.“
The Dopamine released when finding the solution asks for more. We’re not willing to clean the kitchen to ease, maybe, our future work (Present bias). We want to realize another astounding dish today to double our Dopamine dose now and we discount the value over time of cleaning the kitchen now.
And this drives me straight to the point of attention I want to Raise…
‘Released in Production’ is past tense
There’s a moment in the post in which the author describes how a Definition of Done explicitly including the cleaning of code could help us.Everything is great like in all the rest of the post apart from a sentence that I fear a little bit:
“Sometimes we’ll want to put something in production first, then get user feedback, then clean up”
I have one important remark about it.
The sequence of events described in that sentence makes sense for a mature team in certain types of organizations. Actually I’ve seen it happening in that way, as well…
but it makes a lot less sense in many other organizations in which delivery managers are used to challenge teams to push things in production at all costs.
What I observed, in such situations, is a continuous piling up of bad code in Production, the team being constantly exposed to a stressful environment, team members not being trained nor mentored. As a consequence they rarely dare to take ownership of product and project decisions (i.e.: when to deploy) and usually for good reasons.
Just to be clear my opinion is that it is NOT due to some ONTOLOGICAL defect of the developers involved (translation: please stop saying that this happens to mediocre developers and keep the conversation about facts and not people).
Below I describe my interpretation of the mental process that my mind undertook in the past and that I think many other developer’s minds undertook as well.
After all how can we define ‘Done’ when quality is involved?
Is ‘Done’ a discrete status or a continuum, strongly affected by the subjective view of the developer?
It is true that a software developer could refactor and perfect a piece of code until the end of time if needed. But it is true, on the other side, that they simply don’t do it!
They stop somewhere in the middle when they are confident enough that their code will not explode in Production overnight (or during the weekend).
But what actually happens counts less than Parkinson’s Law (“work expands so as to fill the time available for its completion”). In fact it is commonplace to treat developers like if Parkinson’s Law were true science.
Sadly this can cause developers to over-rationalize their choices. It is socially better for them to claim that they can go to Production ergo they start pushing things to production even when they don’t feel safe about it. They somehow fall in the trap of Projection bias and take a decision that will influence their not so happy future selves, over-estimating the parameters apparently important at the moment of the decision (social pressure, doubts about their ability to decide, etc).
But it’s not over here! Usually in the very next instant after having pressed the ‘Deploy’ button, someone with power passes a new request. The team have to deep dive immediately.
This sums up to the ‘Deploy’ action. The team starts this new piece of work. The list of events grows up. The decision we made to clean the code after the release is pushed in the past. The Recency Effect does the rest.
What can we do about it?
Honestly I don’t know.
My only suggestion is to be careful when we talk about going to production with ‘dirty’ code.
There are plenty of teams out there that are struggling to become great teams in adverse conditions.
As is true with many other topics in the ecosystem of Agile and of Software Development, an apparently harmless statement could affect negatively those teams if the statement itself falls into the wrong hands.
Coffee psd created by kues – www.freepik.com
