- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- partnership
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Let’s avoid the equation ai_fragility * software_fragility = very_bad_things
Anyone who has built classical, deterministic software systems can tell you how fragile they are. Such systems perfectly follow precise, explicit instructions, and are incapable of operating outside those instructions. That means that, if you have written instructions which do not specify the behaviour you want, which are inconsistent with one another, or do not cater for unexpected values, your system will fail. If you are lucky, that failure will be loud: a crash with an ugly error message. If you are unlucky, it will be quiet: steady, ongoing corruption of data values which you won’t discover until later.
Anyone who has built newer, AI driven, probabilistic software systems can also tell you how fragile they are. Such systems treat inputs (prompts, context, training data and so on) as factors which affect the probability of getting different outputs. That means that, if your inputs are insufficient to tilt the balance of probabilities in favour of your desired outputs, your system will fail. If you are lucky, that failure will be obvious: results which are factually incorrect or logically incoherent. If you are unlucky, it will be obscure: results with subtle biases which you won’t discover until later.
Failing fast is fun until you fail at scale
Finding bugs in your code is like being betrayed by your own brain.
Sometimes the betrayal is blunt and obvious. The system generates errors or crashes outright. When you look at the code, you realise that you have mis-spelt a variable name (again), or left out punctuation (again), or called the wrong function (again).
Sometimes the betrayal is subtle and insidious. The system appears to be working properly, until you realise that the data in the database is drifting away from reality. When you look at the code, it looks fine, until you wrap your mind around the logic and discover that it is decidedly wonky. And this is logic that you created.
Embrace *all* the fundamentals, of software, of models - and of humans
I sometimes try to persuade business leaders that they should get to grips with the fundamentals of the technology they depend on. This often manifests as an exhortation to learn to code, not because I think they will be great coders (although they might be) or because we need more coders (although we do), but because engaging with the practical reality of building and running systems is the best antidote to the confusion, bewilderment and mystification that surrounds technology. And because they might make better choices about technology partnerships, investment, organisation, sourcing and strategy if they knew more about how it all worked.
For most of my career, this advice has been focused on traditional software: procedural code, written line by line by humans. However, as enterprises are attempting to figure out how to make effective use of AI, I think it is necessary for leaders to get to grips with the fundamentals of three types of work that goes on in their organisations: that carried out by software, that carried out by models, and that carried out by humans. I regularly see people confusing the characteristics of these three types of work, for example, claiming that an AI model is ‘like an intern’, or that there is no more need for a code base of software because AI will either make all the necessary decisions or generate all of the necessary code on demand.
The software paradox: it’s rational to make plans; it’s irrational to expect them to work
Software projects suffer from a paradox. They are typically expensive endeavours which are of great importance to the organisation which is executing them. It is rational to want to be assured that they will be successful, that they will not cost more than the organisation can afford, and that they will not take longer than the organisation can wait. At the same time, they are fundamentally unpredictable. Any software project worth doing involves work which no-one has ever done before, creating new logic and new capabilities, and integrating existing components in complicated and interesting ways. This is difficult work which involves intellectual challenge and problem solving. Things which look hard often turn out to be easy, while (rather more frequently) things which look easy turn out to be hard.
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.)