- 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
Innovation and application
A couple of months ago, I wrote about the book The Elements of Computing Systems, by Noam Nisan and Shimon Schocken, and how it was helping me traverse the layers of abstraction out of which computing is constructed. After many hours of reading, thinking and programming, I am nearing the end, and was struck by a few sentences in the penultimate chapter which are worth quoting in full:
Modern high-level programming languages are rich and powerful. They allow defining and using elaborate abstractions like functions and objects, expressing algorithms using elegant statements, and building data structures of unlimited complexity. In contrast, the hardware platforms on which the programs ultimately run are spartan and minimal.
At a time when Moore’s law has been running for decades, when semiconductor manufacture is an industry of global significance, and when ever more specialised chips are being produced to optimise the performance of artificial intelligence models, it’s easy to forget that, at root, all this silicon is, as Nisan and Schocken say, ‘spartan and minimal’. However we arrange them, the atomic units of computing remain ones and zeroes. (Let’s leave quantum computing to one side for a moment.)
Automation or augmentation?
On 9th December 1968, Douglas Engelbart of the Stanford Research Institure, gave what was later called ‘the mother of all demos’. In a 100 minute session, he demonstrated the capabilities of the oNLine-System (or NLS - they had terrible abbreviations in the 1960s too), including features which we would not see in commercial computing for many years: windows, hyperlinks, real-time collaboration, video-conferencing and the use of a mouse. It’s striking how familiar the experience is (even down to elements of the demo going wrong), and it’s not surprising that Engelbart got a standing ovation at the end.
However, once you get used to seeing technical advance after technical advance, all described in Engelbart’s calm and level voice, one more thing stands out in the demo: the conception of computing as a means to augment what Engelbart calls ‘intellectual work’, a goal which he also makes clear in his paper, Augmenting Human Intellect: A Conceptual Framework. Engelbart decided to pursue computing after the Second World War, with the goal of turning machines which had previously been solely used for calculation into machines which could be used to help people think and work collectively.
More than just a job
Was this the right decision?
In mid-2022, I got a phone call, asking whether I would like to apply to become CTO for the UK Government. I had only been in my current job for a short time, so I said no. That wasn’t the only reason: I had spent almost all of my career in the private sector and understood enough about how things worked in that world to be reasonably helpful and successful. I must also admit that, coming from that world, I did not (yet) perceive work in the public sector as particularly attractive or exciting.
However . . .
At the back of my mind, I felt that I had a debt to pay. My very first paying job in technology was as a COBOL programmer for HM Customs & Excise. Before that job, I was an amateur programmer, but had no degree and no professional qualifications in computing. After two years, I was trained and experienced, and capable of working in a professional technology environment - and, like many of my peers, I took my skills to private industry. I hadn’t been back since.
Make code make sense
Code is a maze. If you don’t leave breadcrumbs, you will get lost.
Most professionals cringe at how their work is portrayed on film and TV. Technology is no different. Hackers who growl, ‘I’m in,’ after bashing away furiously on a keyboard. Complex 3D graphics that supposedly represent a file system. Giant ‘downloading’ progress bars that conveniently fill just before the hero needs to snatch the drive from the unsecured USB port.
But the most egregious portrayal may be the least obtrusive: it happens when the heroes get their hands on a piece of code that is essential to defuse the bomb, or expose the villain, or unlock the door to the cell, or whatever is needed to move the plot along. The code scrolls up the screen, the hacker character squints and scowls at it, then frowns and starts typing. (Occasionally there is a variant, where the hacker stares at the code, wide-eyed, and says something like, ‘It’s beautiful . . . so elegant.’ Spoiler alert for non-programmers: I do not believe that anybody has ever said these words about another person’s code.)
A tale of two codebases
It was the best the code would ever be; it was the worst the code would ever be.
Let me share two stories about software development.
In the first story, I was working on a software project. For the purposes of this story, it doesn’t really matter which one: after a while, all software projects have similar characteristics. But let’s pick a project in which I was helping build a new billing system for a utility company. The project started well, with a structured approach to architecture and requirements, and it seemed that we had all the time in the world. But, as the project progressed, the time vanished. The list of requirements got longer, not shorter. Programs returned from the testing team with more bugs, not fewer. We replanned, and rescheduled, and rebaselined, but didn’t find any magic ways to create more time. However, we crunched through, and eventually broke into the clear: with a bit of nifty rescoping, and expectation setting, and agreement that we had to release something, we launched the system. We survived the first few months of teething problems, and the system settled down. It wasn’t what had originally been envisaged, and the code was full of compromises and inefficiencies. But it was running - and when it was running well enough, the project was shut down and we walked away, some of us to start the next cycle all over again.
Skeuomorphism, refactoring and the persistence of constraints
Whenever I walk through Westminster (which, these days, I do a lot), there are queues of people waiting to take photos outside the red phone boxes that stand in Parliament Square. I can understand why: not only are the red phone boxes attractive symbols of Britishness, but if you line your shot up right, you can get Big Ben in the background.
However, there is an irony in crowds of people using expensive mobile phones to take pictures of the service that you used when you didn’t have a phone - and which has largely been rendered obsolete by those same mobile phones.
We see similar juxtapositions of old and new technology iconography every day, even if we don’t notice it. I’m looking at the home screen of my own mobile phone now, and I can see icons in the shapes of an old telephone handset, an old camera (twice), a wallet containing physical cards, a round clock with hands, and, finally, a mechanical gear wheel. This phenomenon is known as skeuomorphism: the use of old technology to represent new technology. It is remarkable how persistent these symbols are: I recognise them because I grew up with their analogue counterparts, but they are also used confidently by people who have never picked up a physical handset from a cradle, or clicked the button on an old-fashioned camera.
Sometimes it’s fine to have a solution looking for a problem
The lightbulb was not always the symbol of a good idea.
Edison’s incandescent electric lightbulb initially met with scepticism on both sides of the Atlantic. Henry Morton of the Stevens Institute of Technology said that, ‘Everyone acquainted with the subject will recognise it as a conspicuous failure,’ while a British Parliamentary committee said that it was, ‘unworthy of the attention of practical or scientific men.’
Part of the reason for this scepticism was due to problems that had not yet been solved, such as the distribution or ‘subdivision’ of electricity. But part of it was also due to the feeling that these problems did not need to be solved: there were already established ways of providing illumination. Edison’s lightbulb was a solution looking for a problem.
That’s why they call it the future
What does the future look like, seen from the past?
Recently, I’ve been doing a lot of reading about the early days of the public Internet, and revisited the book ‘What Just Happened?’ by James Gleick. It’s a collection of essays about technology, written through the 90s and published in 2002. It was already a time capsule when it was published, and is even more so from the perspective of 2024. For anyone who lived through those times, it’s a mix of nostalgia (dial-up modems; Usenet; multimedia content on CD-ROM), prescience (GPS in your pocket; personalised feeds; digitisation of money) and emerging questions of behaviour and social impact (privacy; etiquette; trust).
The themes I found most interesting, though, were optimism and frustration.
Failure, fairness and friends: development and video games
If you play video games, you may be aware of the Dark Souls series, or the genre of ‘Soulslike’ games. These games have common characteristics: they are third person action adventure games, usually (but not always) set in a fantasy world, where you fight an implacably hostile environment and enemies, including bosses who often tower above you. They have complex, obscure stories that you discover piece by piece, you level up by gathering resources (souls, or runes or something else) from the enemies you kill, and you lose those resources when you get killed - but you can regain them if you fight your way back to the place you died without getting killed. And they’re hard. Very hard.
i enjoy these games (with a few exceptions - ahem Sekiro ahem). Even though they are intense and frustrating, they are very rewarding when you manage to overcome challenges and get to the end. Moreover, they feel fair: when you die to a boss for the fifteenth time, you know that it was because you made a mistake: you dodged slightly too late, or you waited slightly too long to heal, or you pushed your luck a bit too far.
Features are like feathers: you never know how they will be used
We now know that many dinosaurs had feathers. However, this doesn’t mean that all feathered dinosaurs could fly: it is believed that feathers first evolved for insulation rather than flight, and developed over millions more years to provide lift as well as warmth.
Feathers are an example of exaptation: a term proposed by Stephen Jay Gould and Eilsabeth Vrba in 1982, to describe the phenomenon of something that evolved for one purpose, and has been adapted by evolution to serve another purpose. Other examples include the development of two of the bones that formed part of the reptilian jaw to become the malleus and incus, essential parts of the mammalian ear: we hear with bones that reptiles use to eat.
Exaptation is a useful concept in technology too, and we do not have to wait millions of years to see it in action: human ingenuity acts faster than evolution. For example, take the powerful computing devices we carry in our pockets and call ‘mobile phones’.
Technology estimates: unpredictable since 1823
In 1823, Charles Babbage was awarded £1,700 to build a machine known as Difference Engine 1, capable of automatically producing astronomical and mathematical tables. It was to be based on Babbage’s success in building Difference Engine 0, a smaller, prototype machine, which showed the potential of automatic calculation.
Nineteen years later, in 1842, after the budget had been spent ten times over, the project was abandoned. By this time, Babbage’s attention had shifted to an even more ambitious project, the Analytical Engine, which anticipated much of the computing architecture of modern, digital machines, including programs, memory and an arithmetic processing unit. Despite the contributions of another genius, Ada Lovelace, only a small part of the Analytical Engine had been built before Babbage died in 1871.
We should not disparage the work of Babbage and his colleagues for being incomplete: the Analytical Engine may be the best example ever of a machine being ahead of its time. To a modern computer engineer, the idea of building a mechanical digital computer out of brass and steel is audacious, to say the least. To a software engineer, the idea of developing computer programs, as Lovelace, without a machine to run them on, without the fundamentals of computing being settled - and without the modern programmer’s primary resources: the Internet, a search engine and online forums - is terrifying.
Try visiting a different layer of abstraction
I had a brush with assembly language over the Christmas break.
I’ve always counted myself fortunate that I started programming in the microcomputer era, when BASIC was the most common entry point for hobbyists, and that I got my first programming job when assembler programming was becoming rare, and languages such as COBOL were the norm.
BASIC and COBOL are regarded as old-fashioned now, but their core programming paradigm - a simplified, English-like syntax used to construct logic and manipulate variables - endures. However, I’ve always been aware of the assembly programming paradigm that involves loading, incrementing and comparing registers, and that it’s a lot closer to what is actually happening at a hardware level. I’ve also been aware that many large enterprises still depend on code written in assembly language, and have been grateful that I’ve never had to attempt to learn, read or debug it.