- 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
Software development and the problem of akrasia
another episode of the TV programme when we know we should be studying?
In philosophy, these are problems of akrasia, or weakness of the will. Put simply, the puzzle is: if we know that we should do something (or not do something), and we want to do that thing (or not do it), how is it possible that we put it off (or choose to do it)? Why do we do the things that are bad for us, even when we know that we are bad for us?
This might seem to be one of those questions that only a philosopher could worry about. Isn’t it obvious? We eat the extra slice of cake because we like cake, and, in the moment, our pleasure matters more than our long term health. We skip the session at the gym because it seems too much like hard work, especially compared to extra time in bed or another cup of coffee. And we watch more TV instead of studying because we’re caught up in the programme - and there’s always tomorrow.
Engineering for a distant future
How do you give someone a warning when they won’t exist for a hundred millennia?
That’s the problem of long term nuclear waste messages. Aside from all the physical engineering problems of securing radioactive material safely for long periods of time, designers also face the social engineering problem of ensuring that curious or greedy humans won’t undo their work by digging the waste back up again when they have forgotten how dangerous it is.
This problem gets more interesting the longer you think about it. We can’t rely on language: history tells us that languages shift and change in meaning. We can’t rely on the durability of digital media: no storage device we have built so far has lasted longer than decades. We can’t even rely on colours and shapes: these mean different things in different cultures.
Interesting engineering problem #1: survival
That’s the prototype: now we just need to turn it into a production application.
The people at the front of the room clap. They have just been taken through a whirlwind of demoes, slides and post-it notes. They have just been shown what the presenter keeps referring to as the art of the possible, and they never imagined that so much was possible. They want the features that they have been shown, and they want them now.
The people in the middle of the room frown. They are wondering where the resources and budget will come from. They are wondering where the work will fit in their portfolio of projects or on their backlogs. They are anticipating the difficult conversation when they explain that the art of the possible probably means a delivery some time next year.
The people at the back of the room look thoughtful. They are scribbling on pieces of paper, and exchanging notes and ideas with each other. They do not regard the code that they have seen demoed as a product; they do not even regard it as a prototype. At best, it is a child’s drawing of what the product might be when it is finished. The real work has not even started: ‘just’ turning it into a production application betrays a fundamental misunderstanding of what this work is.
Words matter (especially when we don’t know what they mean)
In a recent episode of the wonderful podcast The Skeptics’ Guide to the Universe the guest Chris Smith described an early experience in his medical training. He attended a lecture in which he and his fellow students were subjected to a blizzard of technical terms, to the point where they felt overwhelmed and lost. When they were quizzed on these terms as if they were expected to understand them, they started to question their choice of profession . . . until the lecturer revealed that they had been spoofed. The whole exercise was designed to give them the experience of a layperson confronted by a highly expert medical professional who seems to be speaking a whole other language. There is an obvious parallel in the world of enterprise technology: we are notorious for using impenetrable jargon and expressing complex ideas in terms which no non-technologist could reasonably be expected to understand.
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.