I had a great time last weekend with a garden party with my friend and one of my longstanding tech leads David. It was great to spend the afternoon with friends and work colleagues. Great food, great friends marking the end of summer.
Whilst I was there I recorded an episode of mine and Andy's podcast, Tech from the Top. Normally Andy and I have a chat and blast things that we don't like and sometimes gift a few compliments to people. Age has made us both bitter in the world of Microsoft.
Anyway, we recorded our first podcast in the great outdoors (of David's garden). It's not ready for release yet as my producer Gebriel had to some heavy edits and dubs (don't record podcasts drunk, Ajure sounds like a reasonable name for a cloud but it's totally fictitious).
In the podcast I interview Lis, my incredibly talented Head of Value Creation, who has assembled a squad of crack business and technical commandos to do battle with some of the most insane customer requirements coercing our customers from purely technical asks for no reason at all and no particular users to building out a key validation of something that will actually drive business value. To do this properly you need good technical and business skills. I could go into the philosophy of why this set of people are truly brilliant but I'll save it for another blogpost.
So the theme of the podcast was Don't touch my *!$@%&* board which is an innovation in our understanding of customer behaviour. This blog post is about the frustration of initiative post screw up. Lis talked about how she spends inordinately large amounts of time building agile boards from scratch which hybridise and reflect the minds of our customers and also the minds of developers. The layout and hygiene is a personal nuance that reflects experience of the intangible and just works. The title of the podcast stems from the fact that if you go away for a day or on holiday for a period and somebody else picks up the mantle inevitably they destroy your board if they don't understand this nuance hence Don't touch my *!$@%&* board. Lis isn't the type to stay silent when the board is screwed up and developer's productivity takes a turn for the worst because nothing can be found in a new arcane system of epic and feature munging. I've seen so-called agile experts mess around with my boards and totally misunderstand parent child hierarchy definitions between features, user stories and epics. There's some utter bilge online written by a lot of people in this respect that wouldn't be able to build a software product if it hit them in the face, jumped up and down on their chest proclaiming that they are software product. I empathise with Lis in this respect.
During the podcast she asked me whether I had the same tendency to die a million times over when people touch my code and make it a little more shit, hence the new rule and meme Don't touch my *!$@%&* code was born.
I have to say I never realise vocalise my disdain here. It happens in Elastacloud and in customers but I spend so much time on clean, well-tested code with good software patterns and sometimes, just sometimes I return to it and somebody has let off a nuclear bomb. I try to smile but I realise at that point even the travesty I'm seeing playing out is beyond my skills to fix. True code ninjas shy away from messes like this and there is little you can do except class it as "technical debt", a phenomenon which the worst and most fancy-free of us techies churn out like monkeys with the complete works of Shakespeare and others of us cry at.
At this point you know it's no longer your code; it suffers from a complete lack of testability, chances are that the classic fear-imbued approach that your mentor gave you about a couple of screen loads of code per code file, easy to read naming, declarations of every variable on individual lines, coding standards, separation of concerns so that you can actually find things, tests, DI and everything else that makes cookie-cutter handover so amazing is long gone. You see yourself looking at an untestable logical mess thousands of lines, upon thousands of lines long where everyone is crying and the stakeholders don't realise that the slow rate of progress that a team has is not because the problem is hard but because the solution is shit. It breaks developers, breaks teams and becomes unmaintainable. Everyone who looks at it yet years down the line wants to start all over again.
Don't touch my *!$@%&* code is the story of good code. People that write that first library or first PoC, code MVP are the creative ones that offer a path to all others that come after them. As a community not all developers are built equally. I've worked with some great developers and some that are so bad that their code should be drowned at birth. This podcast really made me think about the responsibility we have to our own code. We are the modern authors of the unfolding of Earth 2.0 and we have a responsibility to all that come after us and touch our code who might be little shit at what they do, to understand and respect the vision of where a simple piece of code could end up if it's treated with the respect it deserves.
Happy trails!