- 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
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.
Are you overfitting your delivery decisions - and to the wrong dataset?
Overfitting is a term from the world of machine learning. It describes the problem that arises when you train a model on a dataset, and use that model to make accurate predictions - as long as they are limited to that dataset. Unfortunately, the model starts to go haywire when you apply it to the wider world.
Imagine a fictional example: you wish to use data about students to predict their academic performance. You train your model on a class where there are several students called ‘Geoff’, and they all happen to be doing very well in their studies - there’s no reason for this: it’s pure coincidence. But the data doesn’t know that. When you make predictions about this class only, your model seems to work: it finds the high performing Geoffs. When you use it to make wider predictions, however, in a world where there are rather fewer Geoffs, and where being a Geoff is not a reliable indicator of academic performance, the model stops working.
Respect before beanbags
I have worked in some strange offices in my career. At a start up, I spent six months in a cramped office above a meat market, where arriving in the morning meant dodging large men in blood smeared coats carrying sides of beef. While working for a large UK bank, which had run out of space in its premises, I spent time in a business continuity centre, surrounded by banks of anonymous desks stretching away into the distance, waiting to be filled in the event of a disaster. As part of a confidential corporate restructuring project, I worked in an empty office scheduled for decommissioning and demolition, hoping that the security systems would keep working for long enough to let the team out in the evening.
And, because I have spent my career in enterprise technology, I have also worked in many environments which look as if they have been outfitted from the ‘digital’ section of the IKEA catalogue, full of bright colours, breakout areas, ping pong tables, expensive chairs - and, of course, bean bags.
Build systems like you hire teams
Despite advances in AI, software systems are not people. But perhaps we should sometimes treat them like people - at least when it comes to budgets and financing.
A couple of weeks ago, I claimed that building software is not like building a bridge, and that the analogy of construction which we use - which I use - so frequently, may be harmful rather than helpful. Rather less usefully, I also suggested that there aren’t any perfect analogies, and that the best way to think about building software is to understand the business of building software. I’m now going to contradict myself and suggest another analogy: that we should think about building software in the same way that we think about hiring teams.
Good standards are like a good starting word in Wordle
What’s your starting word in Wordle?
I use STEAM. It has a good combination of common vowels and common consonants, and for some reason I find it pleasing (something to do with steam engines?). There are words which are mathematically proven to be better, but I like this one.
In case you’re one of the few people who didn’t become familiar with Wordle during the pandemic, I should explain. It’s an online game where you have six attempts to guess a five letter word, and each letter in the guess is marked green, for a correct letter in the correct place, yellow, for a correct letter in the wrong place, or grey for a letter which is not in the word at all. It’s just about hard enough to give you a sense of achievement, but easy enough that you get the right word most of the time. It also has the virtue that everyone who plays the game worldwide gets the same word every day, making it feel as if you are all playing together - you can also share your pattern of green, yellow and grey without giving the game away.
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.