- 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
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.
Don’t stop explaining
Have you ever been tempted to give up trying to explain how technology works? To accept that ‘it’s not about the technology’, that business people only care about outcomes, and to keep the technical details for the people who understand them?
If so, it is worth referring back to a piece of wisdom buried in a footnote of a book on computing from 1953: We apologise for the repetition of much of the subject matter of this chapter elsewhere in this book; it has been our experience that the layman finds it very hard to grasp and follow an account of the operation of a computer, and that he finds it helpful if the whole subject is presented to him several times, particularly if successive treatments are more and more sophisticated . . . In any event it is quite unnecessary to follow all the details of circuits and things: if the fact can be appreciated that circuits exist, and can readily be built, which will perform certain specified functions, that is all that is necessary in order to follow the rest of the book.
Seek solutions that can be understood by anyone - even yourself
“No.”
It wasn’t the answer we were expecting. I was sitting alongside my colleague, in the office of a very senior sponsor and stakeholder. We had just pitched our plan for a complicated, urgent piece of corporate restructuring: the divestment of nearly a fifth of the organisation. It was a time sensitive, strategic and difficult project. My colleague was in charge of the business change plan, and I was in charge of the technology change plan. Between us, we thought we had come up with the best route to success. But our sponsor wasn’t buying it.
“No,” he said again, but this time he elaborated.
“The plan that you have come up with is inventive and clever. If we execute it well, we might just pull this off. It’s efficient, and makes the best use of our limited resources. But there’s a problem. It’s too complicated. I can’t explain this to the thousands of people we’ll need to do the work and expect everybody to keep it straight through months and years of delivery. You’ll have to go away and think of a plan that costs more and takes longer - but is simpler.”
It *is* about the technology (and all of the other stuff too)
It’s not about the technology.
Have you ever said those words? I have said them several times in my career, and heard them many more times. They are usually followed with something like . . . it’s about culture / user experience / business outcomes / customers / change management.
I think that there are good reasons to use these words, and bad reasons to use these words.
They are useful words when we are in danger of losing sight of all the other factors. When building software solutions, it is easy to get lost in the details of tools, components, services and other technical considerations. It is not unusual for technical teams to lose weeks arguing about frameworks and languages, while forgetting about the outcomes that those frameworks and languages are intended to deliver.