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:
We still don't understand one another
In 1864, Charles Babbage wrote, ‘On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" . . . I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.’
It is worth looking at that quotation twice. The first time we see the stupidity of people asking a blatantly ludicrous question. How could anyone imagine that the machine knows what the right numbers are supposed to be? The second time we see the complacency of the technical expert assuming an unrealistic level of understanding in his audience. How could anyone imagine that the audience knows what a brand new machine is capable of?
There’s plenty of room at the top
In 1959, the physicist Richard Feynman gave a famous lecture entitled, ‘There’s plenty of room at the bottom.’ In this lecture, he proposed the idea of tiny, nanoscale machines that would do work, manufacture products, and even become part of our biology.
We don’t yet have nanobots, but we already live in a world of nanoscale technology. Modern silicon chips are made up of nanoscale circuits and are built using nanoscale techniques. We may not have nanobots that manipulate molecules, but we do have nanomachines which manipulate information.
Software is not an asset
Which side of the balance sheet does your software sit on? Is it an asset or a liability?
When people enter the technology profession, they often expect to spend their time solving coding problems – and are surprised to find that they spend much of their time solving accounting problems. It’s an especially shocking revelation when they realise that money comes in at least two flavours – opex and capex, or revenue and capital, or whatever terms are used to distinguish money spent on continuous running costs and money spent on the purchase of new assets. And they thought that regular expressions were difficult to understand.
What does 'architectural significance' mean in the age of AI?
When is a decision architecturally significant?
This question has vexed all of the technology architecture teams and governance structures which I have attempted to set up in my career. The thinking goes something like this: technology is complex and difficult, and we seem to have made some bad choices in the past; it would be a good idea if we were more thoughtful about our choices, and spent time trying to get them right; we could do that through some sort of governance process; however, if we subject every single decision to that governance process, we will erode autonomy and slow everything down; let’s focus our governance process on decisions which are architecturally significant, and let all other decisions be taken locally.
Test environments are from Mars; production environments are from Venus
If a crewed mission makes it to Mars, it will have lots of problems to overcome. The atmosphere is thin, and mostly made of carbon dioxide. The average temperature is -60 degrees Celsius. And there is no magnetic field to shield inhabitants from cosmic radiation. It’s not surprising that, so far, the planet is occupied by robots rather than people.
What about our other planetary neighbour, Venus? It’s slightly easier to get to, has more atmosphere, and is quite a bit warmer. Unfortunately, it’s warmer by about 700 degrees, with an average temperature of 640 degrees Celsius. And that atmosphere is a bit too thick, imposing a crushing pressure 90 times that of Earth. It’s mostly carbon dioxide too, but punctuated by clouds of sulphuric acid gas. And it doesn’t have a magnetic field – or a robot population. The only probes which have entered the Venusian atmosphere have been swiftly crushed and cooked.
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.