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:
There’s plenty of room on the LILO
What are LLMs good for? Everything, if you believe marketing announcements and press releases. Very little, if you believe the most sceptical of sceptics. It sometimes seems that we are still waiting for the crowning innovation, the killer app that will secure the place of LLMs in our enterprise – or the deflating moment when we realise that our expectations cannot be met.
While we are waiting for that moment, I think there is plenty for us to do by putting LLMs to work in relatively mundane contexts. What are they good for? There’s a clue in the name: Large Language Models are good at language, something which traditional computing has been notoriously bad at for most of its existence.
How many placebos do you have in your diary?
In 1955, the researcher Henry K. Beecher published a paper called The Powerful Placebo, which described the placebo effect.
This is the phenomenon that, if you have two groups in a medical trial, and you give one group the drug being tested, and the other group a harmless substitute – a placebo – both groups will show improvement. If you want to know the true effect of the drug, you have to subtract the effect of the placebo.
Haunted legacy: a Halloween code story
It was 17:55 on the 31st October. Five minutes before the programmer’s shift ended and the night shift took over. The time when you hope that no new bugs will be reported and no new tickets will be raised.
Ping!
The ticketing system sounded an alert, and the notification bubble popped back into existence, a bright little ‘1’ in the middle of its red circle.
Return of the spec
How much thinking do you need to do before you start coding?
When I got my first professional programming job, back in the late 1980s, the answer seemed to be all the thinking. We were encouraged - no, obliged - to use a method known as Structured Systems Analysis and Design Method, or SSADM, developed by the UK government. It was the very definition of a Big Upfront Design method, where you had to write multiple layers of specifications, accompanied by a whole array of models which described data structures, data flows and the lift history of data items (it was a very data-oriented method), before you even thought about writing a line of code.
How hard can it be? The power of optimism and naivety.
‘ . . . and now I couldn’t do it because I could see right off there’s no way you could do this. But at that time, we lacked the benefits of age and experience.’ (Ed Roberts, creator of the Altair 8800, the first home computer.)
‘I was so nervous, I felt this is just not going to work - and it worked!’ (Steve Allen, co-founder of Microsoft, on running BASIC on the Altair 8800 for the first time.)
‘We didn’t know what we were doing.’ (Steve Jobs, co-founder of Apple, on creating the Apple I.)
‘How hard can it be?’ What do you think when you hear those words?
Three sentences that I say too often - and will keep on saying
The longer I spend in leadership roles, the more often I find myself saying the same things over and over again. I expect that part of this is due to intellectual laziness – it’s easier to recycle the same thoughts than to have new thoughts. But part of it is because, over the years, I have found leadership principles that work for me, and words which express them concisely.
There are three things in particular which I say a lot, which my team sometimes tells me that I say too much. None of them are original – they are all ideas which I have learnt from others. They are . . .
A moment in the project plan; a lifetime in the codebase
Software can be a source of regret as well as value. It is a common experience to find yourself looking at code and wondering what fool could possibly have written it, only to read the comments and find out that it was you.
The passage from choice to regret is often clear to developers, despite their faulty memories. You knew what you were doing when you made those decisions – and that you (or someone else) would pay for them in the future.
However, this path is not so clear to other stakeholders and non-technical decision makers – and their choices are often the ones that create the most regret.
Welcome to the age of the puppeteer octopus
What will software development teams look like in the age of AI agents? Will they look much the same as today, with the productivity of each team member incrementally enhanced? Will they be hybrid constructs, comprising human members and AI members? Or will there be no teams, just networks of AI agents talking to each other in the absence of human beings?
As we learn more about the potential and limitations of the current form of AI, I become increasingly convinced that we are entering the age of the puppeteer octopus.
Please pay attention to the safety briefing
What do you do when the air crew ask you to put down your books or devices and pay attention to the safety briefing? Do you follow their advice, because this aircraft may be different to those you have flown on before? Do you study the safety card when the briefing is over? Do you check that you know the location of the life jacket, under your seat or in the compartment next to you? Or do you zone out, diving deeper into the mental limbo that air travel induces, waiting for the moment when you can start reading, scrolling or checking emails again?
I expect that most of us regard the safety briefing as a dull but worthy formality, and don’t pay as much attention as we should. However, I also think that perhaps we should regard it differently, and learn some lessons about how we achieve safety in enterprise technology.
The change *is* the system
What do you think of when you think of computer systems? Do you think of a fixed set of features and functions, designed to meet a particular purpose, which changes steadily over time as a result of planned projects or essential maintenance? Or do you think of a dynamic process of continuous change, which adapts to meet a set of needs and opportunities revealed through practice and experience?
Many people who have worked in systems development for a while would favour the second definition: they recognise that a computer system is never ‘done’ and that its capacity for change is one of its most essential features. However, most organisations continue to construct investment plans, portfolios and even balance sheets as if the first definition was correct: IT systems are fixed assets with defined purposes which are built through upfront investment and then depreciated over time.
I was going to do something about legacy technology but I forgot . . .
Have you ever had the weird experience of reading a book and, part way through, realising that you’ve read it before?
Or being recommended a book, going to buy it, and realise that it’s already on your e-reader, marked as read?
Human memory is strange and fallible. It seems that it is possible for us to spend hours engrossed in an activity which occupies our minds, and then completely forget about it.
Do your approvals processes make it easier to do nothing than to do something?
Have you ever seen a project plan which is a victim of the approvals process?
You can usually tell when a plan has suffered in this way. There may be long gaps when nothing is happening, followed by frantic activity around a monthly or quarterly date. Or there may be design and planning work which is crammed into the plan far too early, in order to hit an approvals board. There may even be a whole part of the plan – and the team – dedicated to gathering data and writing requests for approval.
Technology people seem to hate approvals and love them at the same time. Nobody enjoys navigating their way through complicated and arcane processes where every signpost says, ‘Not this way,’ or ‘Try again.’ And yet we don’t seem to be able to stop ourselves from creating more processes: approvals to purchase, approvals to hire, approvals to release, approvals to change, and approvals to change the approvals process. I've certainly been guilty of implementing processes which seemed like a good idea at the time, but less so in practice.