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.
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.
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.
All the things that matter still matter, but they matter more
Hype tends to be, well, hyperbolic.
If you read headlines and social media posts about the use of AI in software development, then you would be forgiven for thinking that is the end of everything. No more developers! No more testers! No more SaaS! English is the only coding language! The death of technologies, practices and industries has been declared many times over the last few years - and yet they seem to keep on going.
If we step away from the hype and take a few deep breaths, I believe that we can see that, while AI will have a disruptive impact on software development, it will be one of amplification rather than dislocation.
Standing on the edge of uncertainty
The practice of software development is being disrupted.
This might not seem like a new phenomenon. Software development is a practice which seems to be subject to continuous change, in an industry which prizes disruption. Over my own career, I have moved from a world in which code was designed according to heavyweight, structured methods, before being written used bare and basic editors, and tested through intense manual effort, to a world in which code is designed, developed and released in short sprints, written in sophisticated development environments, and tested through an automated pipeline.
However, even though programming is not typing, the activity of writing code has been remarkably stable since the invention of high level languages: assembling logical constructs to make the computer do what you want it to do, and then putting one line after another until you are done. And then debugging it until you are actually done. And then continuously improving it, because you are never really done.
Programming is not typing
What does programming look like?
If you believe films and TV programmes, it looks like typing. In a fraught situation, where the hero’s technical sidekick is attempting to defuse a bomb, or ‘hack into the mainframe’ it looks like typing very fast. If it’s the hero who is doing the programming, it looks like typing very fast while wearing sunglasses. If it’s the villain or one of the villain’s minions, it looks like typing very fast in a room with blacked out windows, possibly surrounded by pizza boxes and other debris.
(In one notorious example from a police procedural programme, it looks like two people typing very fast on the same keyboard at the same time. I have no idea what the actors in this programme thought their characters were doing, and suspect that the scriptwriters didn’t either.)
Out of the shadows
Shadow IT is a failure of trust, and it is a failure we must fix.
The origin of the term ‘shadow IT’ is unclear, but you don’t need to know where it came from to understand what it means.
If you work in an IT department, it instantly evokes feelings of dread and horror: of insecure, unmanaged, poorly designed and unstable systems that business teams have come to depend on, and that you’re going to have to figure out how to manage and integrate.
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.