- agents
- AI
- 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
- 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
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Thanks for the panic: can we turn that energy into something useful now?
There have been a lot of big things to worry about related to AI recently: mass loss of jobs, hacking attacks, rogue agents, stock market bubbles, existential threats to humanity, machines with souls, online torture chambers and so on. This worry has been amplified by the weird see-saw positions from AI companies, which go something like: ‘Everything’s going to be great! Unless it’s terrible. Unless it’s great! Unless it’s terrible.’
Panic may seem an appropriate response to such alarming prospects, contradiction and confusion, especially when it feels like there is little that you can do about them personally. Can you use Copilot to compose an email in a way that avoids intellectual decay and environmental catastrophe? Does adding ‘please’ at the end of your prompts (or avoiding doing so) express a position about whether models have rights and consciousness? When you write code that calls an LLM API, are you surrendering or protecting your organisation’s independence and sovereignty? Meaningful engagement feels out of our reach; panic, frustration and the sense of being overwhelmed are always at hand.
We need to explain *how things work*, not just *what they do*
There’s a clip of Bill Gates being interviewed by David Letterman in 1995 that pops up from time to time. It includes a segment where Gates is trying to explain the Internet:
GATES: So everybody can have their own home page. Companies are there, the latest information. It's wild what's going on. You can send electronic mail to people. It is the big new thing.
LETTERMAN: Yeah, but, you know, it's easy to criticize something you don't fully understand, which is my position here --
GATES: Go ahead.
LETTERMAN: -- but I can remember a couple of months ago there was like a big break-through announcement that on the Internet or on some computer deal they were going to broadcast a baseball game, you could listen to a baseball game on your computer, and I just thought to myself, does radio ring a bell? You know what I mean?
It’s a weird time to be a technologist
I never imagined that it would be data centres.
I’ve never worked as a data centre operator, but I have nevertheless spent more of my life than I planned to inside data centres: assessing whether they would meet the needs of the company I was working for, asking questions about capacity and resilience, planning migrations and exits and so on. They’re interesting if you like that kind of thing: if you care about uninterruptible power supplies, about diversity of network and electrical connections, about rack density, heat flow, cooling and fire suppressant systems. That is, they’re interesting if you have a certain type of geeky, specialist, engineering mentality, and particularly if you like thinking about physical constraints.
But for most people, especially business executives, data centres haven’t just been boring: they have been invisible. They know that they are out there somewhere, but they rely on their IT departments to worry about them. For example, I once asked a CEO of a large global organisation how many gallons of diesel he owned, not because I expected him to know the answer, but because I wanted to demonstrate that technology exists in the real world. I was referring to the reservoirs that would run the generators in the event of a failure in the power supply: I suspect he thought I was referring to a commodities trade, or the fuel for the executive limos.
Passkeys show why standards need explaining
I got a new phone recently, with mixed emotions. Delight: it’s a shiny new gadget! Scepticism: is it really that much better than my last phone was when that was new? Regret: could I have eked my old phone out for a bit longer, even though it was getting steadily slower and more full?
And, of course, dread: can I still access all the apps that I need to access? How many of my credentials have transferred seamlessly? How many apps just need a simple re-validation? And how many will trap me in a loop of email resets, forgotten user ids, and notifications sent to devices which I don’t even own any more?
Authentication has been a mess for years. Passwords provide flimsy protection, and companies keep trying to make them stronger by making them more complex: for example, sixteen characters, including numbers and special characters, leading to the absolutely unbreakable ‘Passwordpassword123!’, written on a PostIt note and stuck to the monitor. Password managers and strong password suggestions make them marginally better, at the cost of making password managers a target for attack. Two factor authentication is stronger still, if only providers could agree on what extra factors to use and how to implement them: I currently have four different authenticators on my phone.
This Christmas, give yourself the gift of knowing that your work isn’t boring
‘Sorry, this is the boring bit.’
When I hear those words, my heart sinks almost as much as it used to when I heard someone declare that they were not technical. In the field of enterprise technology, they normally mean that the speaker is about to attempt an explanation of technical detail to an audience which includes non-technical people.
Perhaps they are going to explain to a product manager why the system built for a hundred users can’t scale to a million without extra infrastructure. Or why it’s not a good idea to put a system which holds customer’s personal details into production without security testing. Or why, while it might be tempting to make the chat interface available to every user, someone has to pay for all those tokens.
Business sponsor translation service
It’s tough being the business sponsor of a technology initiative. You want to achieve an outcome; you are responsible for achieving that outcome; it’s your budget that is being spent; and you will be judged on the result. But you are dependent on people you don’t know, concepts that you don’t understand, products that you may never even see, and suppliers that you have never met.
Given how tough the job is, it seems like a good idea not to make it any tougher. However, because business sponsors are rarely experts in technology, they often accidentally make their jobs tougher without realising – sometimes just by saying a few words. Because business sponsors are senior leaders, the things they say have consequences: they prompt the people around them to take action. And, if the sponsor says the wrong things, those actions will be counter-productive.
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?
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.
Building software is not like building a bridge . . . except when it is
Software professionals live in a world of analogies. This is because most people don’t understand how software gets built. This isn’t their fault: the number of people who use software greatly exceeds the number of people who build software for a living, so we have to find creative ways of explaining what is going on. Analogies seem to help.
The most pervasive and persistent analogy is that of construction: we talk about building software as if it like building a bridge. We talk of engineering and we talk of architecture. We talk about foundations, and about building blocks. We might even talk about town planning.
It’s easy to understand why we use this analogy: I have used it thousands of times. We live in buildings. Millions of us live in cities, where buildings dominate our environment. We see them being erected and we see them being demolished. For most of us, they are the most visible and familiar example of something being created. It seems reasonable and helpful to talk to people in terms that they know.
Three quantum lightbulbs
Do you ever have a moment of panic, when you realise that you are lot less prepared for a meeting than you thought you were? I had one last week.
A few months ago, I was asked to run one of the Spotlight on Technology sessions which we regularly hold in CDDO: webinars on computing topics open to all UK public servants. When asked what topic I would like to cover, I casually suggested quantum computing. It was a topic I had done some reading and writing about a couple of years ago, and I thought it would be relatively easy to talk about.
Until last week, when I was preparing for the session. First, I realised that I had forgotten almost everything I learnt two years ago: I had some vague notions of linear algebra and matrix mathematics, and a loose grasp of superposition, but that was it. Second, when I went back and read what I had written, I realised that it didn’t answer all of my questions: I wasn’t confident that I could turn it into an hour long discussion.
Is your frontend fixation robbing your sponsors of agency and accountability?
Text scrolls across the screen. Lights flash and patterns whirl. Images of faces flicker past, overlaid with lines and symbols. The frantic activity slows and settles. One face remains. PERFECT MATCH.
I was watching yet another new police procedural drama. And I was having the same reaction that I always have when they show the user interface for the big computer system that takes three pieces of data and a blurry image, and finds one suspect amongst millions. It doesn’t work that way.
I’m not an expert in police systems or forensic systems, but I know that anyone building any systems has limited time and resources, and they avoid spending those resources on things that aren't necessary. And a user interface that attempts to show all the inner workings of the system isn’t necessary: if you’re lucky, you’ll get a progress bar, a buffering symbol or a spinning ball.
Remember to look down
I had two astonishing experiences while travelling recently.
First, I got on a plane in one country and, some time later, stepped out in another country.
Second, I tapped my phone against the reader on the local metro system and paid for my fare, even though my bank was thousands of miles away.
It might seem that neither of those things are astonishing, but I think that fact is astonishing in itself. It is remarkable how quickly technological miracles become a mundane part of our lives, and we cease to notice how unusual they are.