Attend to your forests, lest they burn
If you have read my previous articles you may notice that many topics come from ideas discussed by Jordan Peterson, who is someone I have been listening to more and more of late. A YouTube channel WordToTheWise recently started to put segments of his talks into motivational videos. I have found these a great format to absorb the ideas, as they are short and well edited. I’m finding it interesting to see how readily biblical ideas can be discussed in the context of psychology and how in turn, they can directly apply to the world of software development.
The video below is a good example of this. The first time I listened to it, a number of ideas jumped straight out at me. As I have replayed it a dozen times, I felt it would be good to write the ideas out to crystallize and share them.
Clear away your Dead Wood
This is a very timely comparison given recent headlines showing the carnage being visited on the Amazon rainforest. It should serve as a powerful reminder to people to keep a clean house, as it is very easy for a blaze to get out of control. It should, yet in software, as in the outside world, we regularly ignore the kindling that is scattered around us, ready to burn. We hoard outdated hardware, run obsolete software on it and are regularly visited by the harbinger of doom, corporate IT. They bring their festive tidings of mandates and critical updates. Things you have to do, because… something, something… dire consequences if you don’t.
Our reaction to these mandates? To try and weasel our way out of them. Avoid at all costs! Why? Peterson speaks to this, it is infinitely more difficult to accept something, when you have not voluntarily chosen to do it. So when a mandate is forced on us we resist it. This resistance doesn’t solve the problem, at best it delays it, so we can suffer another day. At worst it is the match that finally sets off the blaze. So what is the alternative to this?
Adopt the responsibility to do it ourselves!
By opting to take on the responsibility, we gain the opportunity that comes from it, the bloom of innovation. Literally! Innovation is one of those seeds that will not grow unless there is a fire that burns off some dead wood. When you burn off some of your legacy infra or code base, you burn off work that keeps talented minds busy. Busy doing mindless, repetitive work. It frees up space for them to put their energy into growing new solutions to innovative problems.
Anyone that has a clue is aware of this, we all know that old systems suck precious time and resources away from us. So why do we do nothing? The answer comes from the way we manage forests, we need to perform controlled burns. These inherently carry risks. Done wrong you could lose the whole forest. Done right they are it’s salvation and the secret to it blooming. The key, as with anything, is careful preparation and a solid execution. We can choose to adopt the responsibility to burn off our dead wood and in doing so see new life bloom, or we can choose to let the dead wood build, risking a fire that will consume everything.
Your quirks are not always something to be proud of
Outside of a fear of getting burned, another factor that prevents us clearing away the parts of our code that are dead, is our tendency towards accepting the insufficiency inherent in it. Not just accepting it, some are even proud of their insufficient code. Many of us will have come across these code bases, the ones that need special TLC to get them to work correctly. “You just need to follow these decades old deployment steps to make that work. It was the style at the time!”
In many cases however there is no style, no process. It’s just whatever manner that people chose to write the code. I say this, not being critical of others but thinking back on my own code that I have written. With critical eyes, I never followed a style, nor was I encouraged to. I just mashed together whatever worked from Stack Overflow into something that met the basic requirement of functioning.
In complex systems however, this is not sufficient. Styles need to be agreed upon, developers need to follow patterns and practices. This is necessary so that all of the parts of the system can talk to each other coherently. Hell, it’s a basic question that every Java developer gets asked in an interview; “Name the different Java patterns?”. Yet if we were to look critically at our code would we find these patterns? Do we discuss them as a matter of urgency in a code review or are they just assumed as something everybody knows?
It often seems in an Agile world people prefer “emergent design”, as if The Divine is guiding your keystrokes, but this just results in random code and architecture. It doesn’t follow an agreed process or a structure. Worse still, because we created it, our biases make us treat it as if it were pure gold. Anyone who dares to criticise it, is met with the same resistance: “You just don’t get it, man. It’s my style!”
So what is the danger with this? Just let developers do what they need to in order to get something functioning. We don’t need draconian rules and regulations to write code or standards of what infrastructure to use!
Of course there is a danger, it lies in how much quicker we accumulate dead wood when every team re-invents the wheel. Failed attempts result in dead branches that need to be pruned (GitHub lends itself nicely to this analogy). Successful implementations result in more code that will bring more mandates of patches and updates, as they are identical functions that are differentiated only trivially from others.
However when people follow a process or style, they build on the work done by others. Work that has already removed the dead, useless parts from it. Where they find an insufficiency, they strip it away and the process becomes even stronger. By adopting the responsibility to follow a process in your development practice and not clinging to “your style”, more people will collectively learn a better way of coding. By acknowledging your insufficiencies, tackling them and then sharing the lessons from them, more people can share in the wisdom you have found and accelerate their own growth.
Create a Judge
The final part in this that brings this all home is also the part that every Agile team runs a mile from. Set the criteria for your success and your failure. Once you have done that, figure out a way to measure when you are nearing either one of them.
This measurement is often the reason that so many teams run from this, as it invokes a simple, dreaded word. Metrics! The worry with metrics is that they will be reported externally and the team is concerned with how they will be perceived by the “external judge”. The lesson they often miss, the one that Peterson alludes to and is taught in every basic Scrum Master course; whatever metrics the team decide to measure themselves on, they are completely internal. As individuals or a team, you can define your own Judge and set it to your own standards. As above, it is much more easier when it is adopted voluntarily, rather than being forced as a dictate on the the team.
I doubt Peterson has ever attended SM training, but as the ideas are deeply rooted in psychology, he speaks really well to several points related to how teams should operate in retrospectives. Some worth mentioning are:
“If things could be set up for me, the way that I need them to be… what would that look like?”
This is the foundation of the Agile retrospective. A foundation that we often boil down to; “What didn’t go well?”. When you compare it to the question above, it is unbelievable that we chose to word it so simplistically. Perhaps this is an area where we need to elevate our aim and be more precise in the language we use. Asking teams “what didn’t go well?” is a gateway to a bitching session, where they list the woes of the world. Asking teams to consider what an ideal world would look like and what it would take to get there, is a far more fruitful question to ask, despite it being much more difficult to answer. It may be the case that what it would take is outside your control, but at least voicing it puts the ideal into the world. Once the ideal has been made concrete, maybe it is not impossible to make happen, you could break it down into something more manageable and start to measure progress towards it.
“It’s pretty easy to be intimidated in the face of the ideal… from that it is easy to destroy the ideal… if the ideal is too high, lower the damn judge.”
This hits on some of the same core ideals as emergent design. If I’m vague with my goals, then I have no criteria for failure, so everything is success. If I reject the concept of measuring effort in Story Points, then I can dispense with any discussion of increasing the number of points that the team delivers. I’ve fought this battle many times as an SM, when asking the team if they can find an area for improvement. Looking back on it, the mistake was not agreeing and formalising the need for an internal judge in the team. This is something that needs to be negotiated and seen as a pursuit worth investing in. If the team thinks it is too tyrancial then we should lower the judge. However we can not avoid having one if we have any ambition to improve.
“Shape yourself ever more precisely into something that can withstand the tragedy of life.”
Everything in a modern development environment could easily be categorised under “the tragedy of life”. Plans change, servers crash, releases go horribly and customers are never happy. As teams refine themselves and shed the parts that are no longer useful, they become better able to deal with these tragedies. Their backlog process adapts to change, they build in server redundancy, they learn from previous mistakes refining the release process and they listen to their customers, to see how they can make them less unhappy. They continually recapitulate themselves towards being better. This can only be done when they establish a judge, as a guide towards the improvements.
Adopt Responsibility, Voluntarily
You may be thinking, this is all great in theory. If only X or Y was different, I would totally do these, but…
But nothing! All of these come down to the voluntary adoption of responsibility. There is little anyone can do to stop you adopting responsibility of a particular piece of code or technology, if you truly grasp hold of it, fight for it and own it. I have yet to work with an individual or team who genuinely wanted to adopt responsibility of something and been denied their request. That is not to be confused with those that have asked for the right to do something and hesitated at the full breadth of responsibility that comes with that right. That hesitation has cost them the chance to fully control their own destiny but they are in the minority.
You can adopt the responsibility to clean away dead code and stop using infrastructure that is no longer needed. You may not be able to do it all immediately but you can chip away at it.
You can adopt the responsibility to utilise good practices and help reinforce the use of them. Not everyone has to do it day one, but over time they will see how much easier your life is, if you are willing to share lessons with them.
You can adopt the responsibility to create a judge in your own professional career. External to your team or manager if needs be. You may fail to meet the expectations of it from time to time, but you will learn to be more compassionate and disciplined with it.
To paraphrase that damned bear:
Only you can prevent forest fires… provided you adopt the necessary responsibilities to do so.