- 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
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.
Are you under attack from your corporate immune system?
It was supposed to protect us.
One of the most disconcerting aspects of the recent Crowdstrike incident was that the process which caused the disruption - a rapidly deployed update to a piece of endpoint protection software - was meant to prevent disruption. Rapid deployment was intended to help us respond quickly to new threats against which we would otherwise be defenceless. Low level access to the operating system was intended to enable us to detect and deal with anomalous behaviours and subtle modes of attack. Tools such as Crowdstrike are supposed to be vital parts of our immunity against deliberate attacks and accidental failure: they are not supposed to turn on us.
It might seem that incidents such as the Crowdstrike update failure are, mercifully, rare. Most of the time, we rely on our corporate immune system to help us, not to harm us.
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.
Freedom is not free: managing your cognitive and operational economies
Freedom is not free.
Let’s unpack that apparently paradoxical phrase into something a bit more unwieldy, but a little clearer.
In the context of enterprise technology, freedom of choice comes with a cognitive and operational price which we must be sure we want to pay.
The question of freedom versus control in enterprise technology has been debated with varying degrees of heat and passion for as long as the field has existed. Centralised corporate IT functions usually like control. They like to be able to manage costs and risks, to limit the complexity of their architecture and their supply chain, to strive for confidence and predictability. By contrast, development teams and product teams typically like freedom. They like to be able to pick the technologies, frameworks and ways of working which suit them best, to innovate freely, to use their skills and express their professional expertise.
Transistor powered jet skates: seeing the future from the past
‘Look who it is! Iron Man using his jet skates! Those transistor powered wheels of his can do 200 miles an hour!’
If you are familiar with the superhero Iron Man from Marvel movies, you may be surprised by the idea that he would be travelling using skates, rather than flying. However, if you are familiar with electronics, you may be more surprised by the idea that wheels could be transistor powered.
This is a quote from an Iron Man comic in the 1960s. Some things in the comic are the same as the movies of today: Iron Man is a flawed human in a metal suit which enables him to do astonishing things. Some things are very different: the armour is chunky and does a lot more rolling than flying. And, rather than being powered by nanotechnology wizardry, it is powered by transistors.
Complexity and simplicity are friends
How many applications is too many? 100? 200? 1,000? 7,000?
I have worked for many different organisations with different numbers of applications. Whatever the numbers, though, they all had one thing in common: somebody, somewhere thought that we had too many applications.
I have always found this belief puzzling. We build applications because we believe that they have value (otherwise we wouldn’t put so much effort into writing those business cases). We celebrate our success when we implement them. And then we record their existence in our great big list of applications, lament that we have so many, and wish that we had fewer. Is there any other field of endeavour where what we have built moves so quickly from asset to liability (whatever our accounting rules say)?
I believe that people worry about the number of applications in their estate because of an inherent fear of complexity, and because the number of applications is a visible signal of complexity. They perceive that their technology is becoming too costly, too slow and too risky, and they also see that these factors rise in sync with the number of applications. The more stuff they have, the harder it seems to get
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.”
Laziness and improvisation: two programming superpowers
Programming is a superpower.
In comics and films, there are several superheroes whose power is to control machines. Programmers can control machines too, except, rather than extending their hands and screwing up their faces in concentration, they do it by typing on keyboards. (Alright, they may screw their faces up in concentration too.)
Moreover, just like the comics, there are many variants of the programming superpower. Lots of superheroes can fly, but they don’t all fly in the same way: some ride on magnetic waves, some raise winds to lift them and others . . . can just fly, without any attempt at explanation. Similarly, some programmers are great at front ends, some are great at back ends, some are great at performance, and others are great at reliability.
Keeping the lights on
Do you have a line in your IT budget which says something like ‘keep the lights on’ or ‘keep the show on the road’, or ‘maintenance’ or ‘support’ - or even just ‘run?.
Over the years, I have put together IT budgets with at least one of these lines in. They’re a convenient way of signalling to finance people, hovering over their printouts and spreadsheets, ready to wield the red pen or press the delete key, that they’d better not strike out this item. They don’t have to understand technology to understand that, without this money, something will break. They’ll probably ask us to swallow inflation, or to trim around the edges, but they’re unlikely to cancel it altogether.
While this arrangement can be convenient (the IT department gets its money; the finance department does not have to understand technology), I do not believe that it is healthy or helpful. I believe that we would do a better job if we explained exactly what we spend this money on, why it matters, and why it gets more complex and more difficult every year.