- 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
Will conversation save us from frustration?
. . . I will do such things -
What they are yet, I know not; but they shall be
The terrors of the Earth!
These are King Lear’s lines in Act 2, Scene 4, as he rages against his daughters.
Like much of Shakespeare, these lines can be interpreted in distinctly different ways. I have seen them played as threats of fathomless malice: I shall do such terrible things that they cannot even be named. And I have seen them played as expressions of impotence and frustration: I am so powerless that I cannot even say what I will do.
We might think that, in our normal lives, we could not attain the towering anger of a mythic and tragic figure such as Lear. Yet it is remarkable how frequently, when faced with even little frustrations, we find ourselves uttering curses that might rival Shakespeare for venom and invention.
What if we could see software?
One problem with software is that we can’t see it.
This might seem like a strange thing to say. Don’t we see software all the time? I am looking at a word processor embedded in a browser as I type these words. If I get interrupted (as I inevitably will) by a message or a call, I will see and touch a software defined interface on my phone. This software was written by human beings staring at lines of code on screens. If I doubt the existence of this code, then I can hop across to one of many public code repositories, and see millions of lines of it for myself.
Yet none of these experiences really count as seeing software. When I use my word processor, I simply see the behaviour which the software presents to me. When I pick up my phone, I merely see a veneer on top of a whole network of applications and interactions which work together to get messages to me. And when I look at actual code, I only see a tiny fraction of software at a time. Anybody who has tried to hold multiple sections of code in their head at the same time knows how quickly your memory fills up - and how fragile it is.
Breaking the cloud barrier
On October 14th, 1947, Chuck Yeager became the first human to break the sound barrier, flying the Bell X-1 experimental plane. Prior to that event, there had been serious doubt about whether it was possible to break the sound barrier at all: aircraft approaching the barrier had experienced buffeting, instability and even crashes. However, Yeager’s flight was remarkably smooth: his plane had been designed for supersonic flight. Yeager later said, ‘I realized that the mission had to end in a let-down because the real barrier wasn’t in the sky but in our knowledge and experience of supersonic flight.’ Your and my definition of a let-down may vary from Yeager’s definition.
I believe that the experience of human efforts to break the sound barrier is analogous to enterprise efforts to adopt new technology. Right now, this is particularly apparent in the adoption of public cloud. Despite being convinced of the advantages of software defined, elastic, on-demand platforms, every organisation seems to have its own version of the sound barrier when it comes to cloud. Let’s call it the cloud barrier.
A mishap on Mars
On September 23rd, 1999, the Mars Climate Orbiter fired its thrusters for a manoeuvre that would bring it into a stable orbit 226 kilometres above the Martian surface. From this orbit, it would gather valuable information about weather systems on Mars, as well as acting as the communication relay for subsequent missions. 226 kilometres was a safe height, well above the 80 kilometeres at which the atmosphere would be thick enough to cause problems.
But the manoeuvre went wrong, The Orbiter dropped to an altitude of 57 kilometres, and either burnt up in the atmosphere, or skipped off and flew away from Mars altogether. Whatever happened, it was never heard from again.
The investigation found that the problem was due to a mismatch in the units used by the different systems used to calculate and control the craft’s manouevres. One system was working in pound-force seconds (an Imperial measure), while the other was working in newton-seconds (a metric measure). The ratio between these units is 4.45:1 - no wonder the craft crashed.
Enterprise technology and the mysteries of the universe
In 1933 our understanding of the universe changed. Fritz Zwicky, a Swiss Astronomer working in California, observed that the Coma cluster of galaxies was rotating so fast that there was simply not enough mass to hold it together. The cluster shouldn’t exist. He termed the phrase ‘dunkle Materie’, or ‘dark matter’, to give a label to the missing mass that must be holding it together through the force of gravity.
It took decades for the concept of dark matter to be accepted more widely, but it is now a part of our standard description of the universe. We still don’t know what dark matter is, but believe that it outweighs normal matter by a factor of more than five to one.
That’s an astonishing thought. Everything that we can see - the Earth, the Sun, the stars, ourselves - makes up only a fraction of the matter that exists in the Universe.
Do you wish to proceed? y/n
If you play video games, particularly adventures that take many hours to complete, you may be familiar with an experience you sometimes get just before the end. The list of sidequests is dwindling and you have run all the errands for your party members. You suspect that you are nearing the conclusion of the story, when an option pops up, something like this:
Do you want to proceed? (You will not be able to return past this point.)
If you’re anything like me, when you see this option for the first time, you say no, you save your game, you check your inventory, you upgrade everything that you can upgrade, and you save your game again for good measure. And then you say yes.
If you don’t play video games, you can get the same feeling by administering a computer, even if it’s just your own laptop. Sooner or later you will get prompted to apply an upgrade, accompanied by a message something like this:
Do you wish to proceed? y/n
From the ZX81 to ChatGPT: code matters
The Sinclair ZX81 turned 42 recently (it was launched on the 5th March 1981). 42 seems an appropriate age to celebrate the existence of the machine which gave many people in the UK (including me) their first proper experience of computing. It may not have been the answer to Life, the Universe and Everything, but it was an answer to the question of how to make computing accessible to a lot more people.
For anyone who is not familiar with the ZX81, it was a small, cheap home computer invented by Sir Clive Sinclair, the founder of Sinclair Research. It had one kilobyte of memory, expandable to 16 KB through the famously temperamental and wobbly RAM pack, and relied on cassette tapes to store data.
Despite its age, and the massive disparities in power, the ZX81 has some notable parallels with technology that we use today. It was a flat, black piece of plastic, much like the flat black devices that occupy our pockets and backpacks – although you had to plug it into a TV to get it to display anything, and nobody who spent any time typing on its keyboard would describe it as touch ‘sensitive’ with a straight face. It was also a personal device: unlike the shared computers at schools, universities and businesses, this machine was typically the cherished possession of one person. And, despite this personal nature, the ZX81 and home computers like it created a crude form of social network, made up of programs typed in from magazines, games on tapes, and heated playground discussions about which machine was best.
Is there a human shaped hole in your technology plans?
If you’ve been watching The Last of Us then one of the things you will have noticed (alongside the great acting and story) is the eerie feeling of a human world with no humans: an empty world except for nature, a few survivors and, of course, the infected. I sometimes get that same eerie feeling when looking at plans for technology change: where are all the humans?
This is strange, because humans have been at the heart of new movements in the ways we build and run technology for decades.
The Agile Manifesto was published in 2001. Almost all of its 73 words (including the title) concern people, behaviour and communication rather than technology and tools. (Indeed, people and behaviour over technology and tools could almost be a line from the Agile Manifesto.)
The first DevOps days conference was held in 2009. You can still go and read the program (although if you try to follow the links to other sites in the reactions section, you get a great demonstration of link rot). While a lot of the agenda was clearly quite technical, much of it was focused on people, behaviours and communication. Do user stories really help express non-functional requirements? What does automation mean for sysadmins and development teams? How can practices followed by software developers be applied to operations?
Technology architects: be wary of spaghetti and sceptical of lasagne
There’s an old joke that technology architects spend their time turning spaghetti into lasagne. Whenever we inherit an existing architecture, we map the systems, draw the interactions between them, and immediately declare it to be a big ball of spaghetti: a chaotic mess of connections which it is impossible to make sense of. We then draw a lasagne diagram, in which everything is neatly organised into layers. Here are our front-ends, here are our back-ends, here is our orchestration layer, and so on. Now, can we please have lots of money to convert one type of pasta dish into the other?
I must admit that I have built many business cases, presentations and documents which promise to turn spaghetti into lasagne. Sometimes, I have even used the tactic of representing the current state using a physical diagram of interfaces and connections: a picture that, in any architecture of even moderate complexity, rapidly becomes illegible. Why would anybody choose to stay in that start, when we could build the neatly layered target state shown on the next slide?
Who said that adopting the cloud was going to be fair?
It’s not fair!
The cry of the outraged sibling through the ages. Why is my older sibling allowed to go places that I’m not allowed to go? Why is my younger sibling tolerated and indulged, when I would be punished for the same behaviour?
I suspect that many enterprise technologists feel the same way about the treatment of public cloud in their organisations, compared to the treatment of their on-premise infrastructure, even though they are too professional to wail, It’s not fair!
Why is it, they ask, that they are made to jump through multiple hoops to ensure that their encryption standards and approaches to key management are watertight on cloud, while on-premise, most of their data is unencrypted? Why is it, they go on to ask, that their risk teams fret about the distance between zones and regions, when their on-premise infrastructure is crammed into twin data centres which are overdue for refurbishment? Why is it, they lament (they’re on a roll now), that everything they do must be automated and instrumented, while on-premise infrastructure is still maintained through manual processes that take weeks to complete - if they are ever completed at all?
Are you breaking up monoliths or creating rubble piles?
This week I learnt (via the wonderful Skeptics' Guide to the Universe) that asteroids in the solar system come in two varieties: monoliths and rubble piles. These are exactly what they sound like: monoliths are big, singular rocks, while rubble piles are, well, piles of rubble, held together by gravity.
Rubble piles have a couple of interesting properties. First, the oldest asteroids are rubble piles. This makes sense: if a monolith experiences a collision and gets broken up, it may become a rubble pile. But there’s no way for a rock pile to go back to being a monolith. Second, rubble piles are harder to move. If we detect a big monolith heading towards Earth, we may be able to change its trajectory with a single impact. But if we send something up to impact a rubble pile, it might just jiggle around and do nothing to stop it coming towards us.
On meeting the first robot of Spring
When do we get signals of the future?
I got such a signal this week. I was travelling for business and, as I walked through the airport terminal, I met a robot. Well, perhaps met is too strong a word. I was looking for the check-in desk and it was cleaning the floor. We weren’t introduced and we didn’t talk to each other. But it was definitely a robot: it was about as high as my waist, it was moving around autonomously, and it had a complicated configuration of wheels and brushes at floor level. I know that vacuuming and cleaning robots have been around for some time, but those little hockey pucks somehow never quite felt worthy of the name robot: they didn’t have the heft and presence of the science fiction robots of my youth. This was a proper robot: big enough that it occupied the same space as humans. I hoped that its collision detection was working properly.