- 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
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
It’s more complicated on the inside than it is on the outside
We don’t need time machines to create paradoxes in technology: they are built into the way we work. One of these paradoxes is that the simpler technology appears on the outside, the more complicated it is on the inside.
I was reminded of this recently when talking to someone who confidently told me that the more sophisticated AI models get, the easier they will be to use, for technologists as well as end users. AI would solve its own skills problem. I was surprised by this because, to me (and, I expect to most other technologists), while we understand how natural language interfaces can radically simplify the experience for end users, the introduction of the current wave of AI into our architecture makes it more complicated.
Learn to fail fast? Technologists fail all the time
From time to time, organisations attempt to learn new ways of working. They attempt to become digital or agile or data-driven or innovative. These attempts come with some familiar ideas: that we should execute through cross-functional teams who are empowered to experiment. One of these ideas is that we should not be scared of failure, and that we should learn to fail fast.
These attempts sometimes elicit eye rolls from the technology teams, especially the idea that we should embrace failure. This is not because these ideas are invalid: in fact, they are welcome to technology teams, and reflect their preferred ways of working. However, technologists have a different relationship with failure than non-technologists.
Are LLMs the air fryers of AI?
Do you know someone who got an air fryer for Christmas? Or did you get one yourself?
If you know someone who got an air fryer, then there’s a high chance that you have heard all about it, and how it has been a complete game changer. They can cook things in a fraction of the time it used to take! And it’s not a fryer at all - it’s really a mini-oven! If you got an air fryer yourself, then there’s a chance that you’ve used it for everything, and that, even now, you are thinking about what you could use it to cook next.
I don’t have an air fryer myself, but am old enough to remember when my family first got a microwave. We lived off jacket potatoes for at least a week, and tried microwaving many things that should not be microwaved (there’s a reason that roasts are called roasts). Eventually, we found, just as my friends with air fryers seem to be finding in the weeks after Christmas, that, while the microwave is a useful tool to have in the kitchen, it’s not the only answer, and certainly not the best answer for everything.
On the 2025 to-do list: figure out AI agents
Recent years have seen waves of AI innovation breaking faster than we can figure out good practice. Organisations around the world are working hard, not only to find ways to put AI to work, but to do so safely and responsibly. The AI to-do list often seems to be growing longer faster than we can strike items off it - but the only route to good practice is practice.
The advent of AI agents promises to add more items to the to-do list. The AI agent wave started cresting in 2024, and will break in 2025. Several major technology vendors and platforms already offer their customers the ability to build, configure and operate AI agents in an enterprise context, and the ability for consumers to build agents or to subscribe to existing agents, cannot be far behind (indeed, it is likely that, by the time this article is published, it will already be happening).
Embrace the gift of boredom this Christmas
It’s Boxing Day today, which means that, if you live in the United Kingdom, you are entering the limbo period between Christmas Day and New Year’s Eve. (Other countries may have the same experience, but I have only ever celebrated Christmas in the UK, with our holiday timing and traditions.) The presents have been opened, and the Christmas dinner has been eaten. Batteries have been found for the toys that needed them, but they’re starting to run down. The board games have been played, and you are wondering when your relatives are going home. It’s dark outside and it’s possibly raining. Most of the shops are shut. In theory, tomorrow is a working day, but lots of people are still on holiday.
You might feel a bit aimless during this period. Possibly even a little . . . bored?
At this point, you may be tempted to reach for one of the distraction devices that most of us have to hand (you may even be reading this article on one of them). Perhaps what’s needed to brighten up these midwinter days is to scroll through a social media feed, to reply to all of the messages in the chat group, to scan the news, or have a quick go on a mobile game.
Or perhaps not.
All I want for Christmas is speed and reliability
What were your Christmas lists like as a child? Were they modest requests for improving books and educational toys? Or were they, like most Christmas lists, an extravaganza of wishes, containing toys and sweets and games . . . and possibly a dragon and a unicorn?
It sometimes feels like our requirements for software development are like a Christmas list written by a very small child that wants everything at once. We’d like the ERP package to have world class embedded processes, but we’d also like it to customise it to meet our every need. We’d like the cloud platform to give us capacity on demand and pay as we go, but we’d also like it to be on-premise because we’re worried about security. We’d like an AI system that predicts our customer’s needs, but we’d like to do it without using our data.
And being a project manager or a product owner can feel like a harried parent who can’t possibly afford everything on the list, and is worried that Christmas morning is going to be a disappointment. If I give them all the customisations they want, then we can never take the upgrade. I can give them security on cloud, but they’ve got to understand the shared responsibility model. I can build them an AI model, but not unless someone’s prepared to share the data.
Precision is not pedantry; clarity is not cynicism
The Nomenclature Committee of the Association of Computing Machinery might not sound very exciting. However, it got to decide the words that we use to describe computers, and words matter: naming is a powerful act. When the computing pioneer, Grace Hopper, chaired the committee in the 1950s, she steered them to avoid ‘words of the magic brain class’, and to use terms such as ‘storage’ instead of ‘memory’, and ‘processing’ instead of ‘thinking’.
This direction was needed in the 1950s. Computers were new, and to most people they seemed like magic. Even though the computation they performed was complex - since the early days, computers had been used for hard mathematical problems such as code breaking and navigation - they did far less than the computers we have today. Today, it would seem strange to describe a machine that was limited to mathematical operations (no speech, no graphics, no sound) as thinking. Yet, in those early days, it was astonishing that computers could compute at all: that they could do work previously reserved for the human brain and mind. It is unsurprising that they were described with breathless excitement.
Playing the triangle: breaking down technology risk
What’s more risky? Building a hotel on the side of a volcano, or trying to deliver a software project?
Years ago, while working for a bank, I heard a talk from a colleague in the Structured Finance team: this team created complicated lending structures for projects that carried high degrees of risk. He told a story about a loan for a hospitality business that was building a new resort on the side of a volcano. Unsurprisingly, that project required some complicated risk models.
I put up my hand and asked, ‘How do you model risk for IT projects?’
The banker smiled and shook his head.
‘We don’t,’ he said. ‘Far too risky. They fail all the time and we don’t know why.’
An infinity of interesting problems
In 1944, Grace Hopper was working on the Mark 1 Harvard computer, solving mathematical problems for the US military. The machine had a clock speed of three hertz - three cycles per second. That’s not three million, three thousand, or even three hundred - it’s three. By contrast, today’s processor speeds are measured in gigahertz, billions of cycles per second. In order to get more power out of the machine, Hopper and her colleagues figured out ways to inject more instructions into the machine in what would otherwise have been idle cycles: an early form of parallel processing.
Across the Atlantic, in Bletchley Park, Tommy Flowers faced a similar problem, but adopted a different solution. The Heath Robinson machines intended to break even more complex codes than Enigma, lived up to their name - they were complicated and prone to failure. He proposed to replace the electromechanical relays with vacuum tubes, creating the first ever electronic computer. His colleagues were sceptical, until Flowers and his colleagues proved that a computer could be built from electronic parts, and could run thousands of times faster than the alternative.
In the 1960s, Margaret Hamilton and her team in MIT were writing the software for the Apollo Guidance Computer, the machine that the Moon mission would depend on. The size and weight of the machine were severely constrained, to the extent that the computer architecture only had three binary digits available to encode each command. If you know your binary, you’ll realise that three binary digits only have room for eight numbers - and eight commands are not enough to get a spacecraft to the Moon and back. Hamilton’s team came up with ingenious ways to extend the AGC’s core vocabulary to just under fifty commands - and then built an interpreter to extend the vocabulary even further and code in a language that was easier to understand.
Embrace the low-coders and the no-coders (and perhaps even the GPTers)
In the early 1950s, there was a problem with programming. Digital computers offered the promise of automation and innovation: the press was full of reports about the wonders of ‘electronic brains’. But it had become apparent that just having computers was not enough: to do useful work, they had to be programmed, and programming turned out to be hard.
It’s important to remember what programming meant in those early days. It did not mean opening up an IDE: there were no IDEs, there were no text editors, there weren’t even any screens. It did not mean importing libraries, or entering commands in a language which looked like English. It meant breaking down every problem into mathematics, and then breaking the maths down into basic arithmetic and atomic logic. The primary productivity innovation was the creation of assembly languages: symbols and mnemonics to make it easier to shuttle numbers in and out of memory and perform operations on them - but even these languages were only one step away from the physical hardware.
Practice takes practice: don’t mistake AI proliferation for maturity
“This is only a foretaste of what is to come and only the shadow of what is going to be.”
These words appear on the fifty pound note issued by the Bank of England, under the portrait of their speaker, Alan Turing. They come from an interview with Turing in The Times in 1949, and continue, “We have to have some experience with the machine before we really know its capabilities. It may take years before we settle down to the new possibilities, but I do not see why it should not enter any one of the fields normally covered by the human intellect, and eventually compete on equal terms.”
The current wave of innovation in AI has led to more excitement about the last part of this quote than the rest, “I do not see why it should not enter any one of the fields normally covered by the human intellect, and eventually compete on equal terms.” Much of the press and social media, along with masses of marketing material, would have us believe that AI models are already competing on equal terms with humans, even if every article about how an AI model has passed the bar exam, or leapt some other professional hurdle, seems to be offset by another article questioning the legitimacy of the test, and yet another giving examples of how the model got things wrong in hilarious ways.
Don’t talk to me about legacy: I’ve got wax in my ears
I learnt a new concept this week, from Cory Doctorow's blog: the idea of the Ulysses Pact. It comes from the part of the Odyssey where the Greek hero orders his men to tie him to the mast of his ship as they approach the lair of the Sirens, monsters whose songs lure sailors onto the rocks. Ulysses’ crew will follow the standard remedy of blocking their ears with wax, while Ulysses will become the first person to hear the deadly song and survive. As well as ordering the crew to tie him up, Ulysses tells them that, no matter what he says, no matter how much he threatens or implores them, they must not set him free.
The idea of the Ulysses Pact is for those times when we know that we will be tempted in the future to act against the values, instincts and interests that we have now. Unless we are unusually self-disciplined, we have this experience every time we embark on a diet, or exercise regime, or a course of learning: we want the good intentions of today to override the temptations of tomorrow. We adopt tactics such as purging our house of snacks, or putting gym and study sessions into our diaries. We lash ourselves to the mast of self-improvement and hope that the bonds are strong enough.