I’m David Knott. I’ve been working in enterprise technology for over forty years and I’m still learning. This blog is based on mistakes, failures, lessons and some things I find interesting:
The happiness of the unhappy paths
As vibe coding continues its rapid journey from concept to trend to practice to product, experienced engineers watch with curiosity, unease - and a sense of familiarity.
If you haven’t already encountered this idea, then you may not have been paying attention to your social media feed for the last few months. The idea is that coding tools powered by Large Language Models enable users to describe in plain natural language what they want out of a program, and the tool generates the code. It can even install libraries, run commands and respond to error messages. Like many processes that involve LLMs, the user prompts and nudges and cajoles the tool until it has produced something that they want. Initially, this approach was suggested as a great way to build prototypes, demos and hobby projects but, inevitably, code built this way is finding its way into production.
The time to care about code quality is now
What do we talk about when we talk about legacy technology?
Sometimes we talk about infrastructure: hardware that is out of support, operating systems which have not been patched or tools which are out of date. And sometimes we talk about commercial software: packages that have not been updated in years, products which are no longer made, and vendors which have gone out of business.
These forms of legacy can dominate our talk, as they present the most immediate and obvious threats: the unpatched server that is a beacon for attackers, the ancient hardware that may never turn back on again if we lose power, and the support line that just rings and rings.
Sometimes I just want a blank sheet of paper (and sometimes I don't)
I call it the pushback moment.
It’s that moment when I am writing something - it might be a work document, or a presentation, or one of these articles - when it’s just not working. The sentences are tangled, the meaning is muddy, and I am not getting my point across.
That’s when I push back all of the papers and references and notebooks from my desk and reach for a fresh, blank sheet of paper (or, digitally, open another browser tab and create an empty document). And I ask myself a question: ‘What am I trying to say?’
Technology architects aren't vampires: they don't need to be invited in
Vampires are puzzling. They have all sorts of rules which help make dramatic stories and films, but which don’t make much sense if you stop to think about them. For example, consider the rule that vampires can’t enter a house unless they have been invited in. Does it matter if the inviter lives at the house or not? What if the vampire receives a party invitation in the post? Is it okay if they are the +1 rather than invitee? Does a ‘Welcome’ mat work? It’s probably best for us not to ask too many questions, but just to accept the rules and enjoy the story. Oh no! The protagonist has blithely invited the monster in for a cup of tea!
However, while this seems strange in fiction, we often encounter its equivalent in real life, especially if we work in the technology department.
Exercise your mind, body . . . and code
I had two humbling experiences last week.
First, I returned from a two week holiday which I enjoyed greatly - but did very little exercise other than walking. When I resumed my normal exercise regime - nothing too strenuous, but something every day - I was surprised that I found it so hard, and why I felt increasingly stiff and sore as the week progressed. It was a reminder of how quickly you can lose good habits, and how quickly their effects fade.
Second, I did some work on a personal coding project which I hadn’t touched for a few months. I went through the normal experience of being baffled by my own code, before gradually remembering the concepts and structures (and, as usual, puzzling at some of the coding choices I made several years ago). I then tried to make some changes and run the deployment pipeline - and everything crashed. I made some more changes, and everything crashed again. And again.
Adventures in ignorance
Nobody knows anything.
That’s the number one rule in Adventures in the Screen Trade, the book by the late screenwriter and author William Goldman (Butch Cassidy and the Sundance Kid, Marathon Man, All the President’s Men and The Princess Bride, amongst many others). Goldman’s insight was that, even though the film industry was getting on for a century old when he was writing in 1996, no-one had been able to figure out what would be a hit and what would be a flop. Nearly thirty years later, it appears that it’s still true that nobody knows anything: despite algorithmic targeting, despite new ways of reaching audiences and measuring their reactions, it is still possible for juggernaut franchises to stutter and stumble, while unknown newcomers charm and delight.
Worry about the dumb machines as well as the smart ones
We have been warned about the dangers of intelligent machines for over 150 years. In his satirical novel Erewhon by Samuel Butler, published in 1872, the protagonist visits a mythical country where machines have been outlawed. The novel quotes the fictional Book of Machines, the supposed trigger for a civil war between ‘machinists’ and ‘non-machinists’: I fear none of the existing machines; what I fear is the extraordinary rapidity with which they are becoming something very different to what they are at present. No class of beings have in any time past made so rapid a movement forward.
There's always a bigger goat: don't let big problems stop you solving smaller problems
In the story of the three billy goats gruff, the goats want to cross a bridge guarded by a troll. They manage this by each telling the troll that there is a bigger goat just behind them until (spoiler alert!) the biggest goat comes along and butts the troll into the sky.
Sometimes, when we are trying to make the case for enterprise technology capabilities, it feels like we are the trolls, and that we are so scared of the biggest billy goat that we won’t tackle the smaller goats. When we look across our technology landscapes, we see mess, waste and mayhem, and wish that we had some of the foundational capabilities that would help clean things up. Yet we hesitate, because we know that every time we build something we will uncover another problem, and another problem, and another problem, until we get to problems that are so big that we cannot imagine how to solve them.
Which are more dangerous: slides, or sticky notes?
In the story of the three billy goats gruff, the goats want to cross a bridge guarded by a troll. They manage this by each telling the troll that there is a bigger goat just behind them until (spoiler alert!) the biggest goat comes along and butts the troll into the sky.
Sometimes, when we are trying to make the case for enterprise technology capabilities, it feels like we are the trolls, and that we are so scared of the biggest billy goat that we won’t tackle the smaller goats. When we look across our technology landscapes, we see mess, waste and mayhem, and wish that we had some of the foundational capabilities that would help clean things up. Yet we hesitate, because we know that every time we build something we will uncover another problem, and another problem, and another problem, until we get to problems that are so big that we cannot imagine how to solve them.
The language illusion, doubled
Is programming a computer more like language or more like maths?
Neither, it turns out. In recent research, neuroscientists at MIT conducted brain scans of programmers while they were trying to solve problems, and discovered that, rather than engaging the language centres of the brain, they engaged a system known as the multiple demand network, usually used for complex problem solving.
Programming languages, it seems, are not the same as ordinary languages. This is not new news. In the earliest days of programming, when Grace Hopper was inventing high level languages, she and her team sent versions of their code to their bosses in French and German. The bosses sat up and paid attention: was it possible that their computers had suddenly learnt to speak foreign languages?
Technologists are always crying wolf (because of all the wolves)
The computer had failed. Unfortunately, it was the Apollo Guidance Computer (AGC), the machine that controlled the flight of a small, fragile spacecraft to the Moon and back. Fortunately, it wasn’t in space: it was on the ground, in a simulator.
Margaret Hamilton, the leader of the MIT team programming the AGC, often had to work weekends to meet the urgent schedule of the Apollo programme, and sometimes brought her daughter, Lauren, to work with her. Lauren liked to play in the simulator.
Coping with volatility: don't panic; seek truth; release frequently
If you’re in the last stages of a multi-year digital delivery programme, then you probably feel frazzled. That’s the normal condition of late stage programme teams. If your programme has coincided with the last five years (five year digital delivery programmes are still a thing) then you must feel frazzled to a historic degree.