- 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
Time to move
During last year’s Mental Health Awareness Week, I delayed writing about my own experiences, mostly because I thought I didn’t have the right: I am not a medical professional, and I have no diagnosed mental health conditions. However, writing about a time when I experienced stress at work made me realise that mental health is a topic for everybody. It seems obvious to say that we all have a level of mental health, just as we all have a level of physical health, but we often don’t talk about it in that way: we only think about mental health when something is going wrong, rather than as a state of being.
This year feels easier, because the theme of this year’s Mental Health Awareness Week is movement: a topic with an effect on mental health which I have felt directly in recent years.
I was not a sporty child. I would rather read a book than play football (that hasn’t changed: I would still rather read a book than play football - I don’t like football). Moreover, I dreaded PE lessons, would risk the consequences of ‘forgetting’ my kit before climbing a rope, and was the proverbially last picked person in team sports. I found a few physical activities which I enjoyed, including canoeing and kayaking, but never really committed to them. As a consequence, exercise did not become a habit in my adult life.
Riding the rollercoaster of reaction and reality
Rollercoasters are strange.
They are arrangements of reality which cause sensations of acceleration and falling which would normally signal extreme peril - but in a safe environment. They are one of many examples of how humans use aspects of our psychology and physiology to create excitement, just like thrillers, horror films, ski-ing and skydiving. It seems that humans enjoy emulations of danger in situations which we control.
Someone observing the enterprise technology industry might conclude that it is subject to the same drives, especially when we ride the technology hype cycle, which looks and feels like an especially precipitous rollercoaster.
Foundations of sand
When the 18th century Scottish philosopher was formulating his sceptical philosophy, he experienced a crisis of confidence, writing in the Treatise of Human Nature:
Where am I, or what? From what causes do I derive my existence, and to what condition shall I return? ... I am confounded with all these questions, and begin to fancy myself in the most deplorable condition imaginable, environed with the deepest darkness, and utterly deprived of the use of every member and faculty.
Fortunately, Hume finds that the concerns and distractions of every day life serve to dispel this gloom: that there is a way to doubt the very foundations of the world, and yet still to go on:
I dine, I play a game of backgammon, I converse, and am merry with my friends. And when, after three or four hours' amusement, I would return to these speculations, they appear so cold, and strained, and ridiculous, that I cannot find in my heart to enter into them any farther.
Innovation as application: a murmur from the mumble-tank
What was that?
A modest stone plaque on a street corner, part overgrown with leaves. My wife and I were heading home from an exhibition at Olympia when we spotted it.
LEO
LYONS ELECTRONIC OFFICE
THE WORLD’S FIRST BUSINESS COMPUTER
WAS BUILT AND OPERATED NEAR HERE
BY J LYONS AND CO
FROM NOVEMBER 1951
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.)