- 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
When is the full stack too full?
Which prefixes would you like with your Ops?
Would you like some DataOps, some FinOps, some GitOps, some ChatOps, some DevSecOps, or would you prefer to go with classic DevOps? (You may, not, by the way, simply choose Ops.)
Since the dawn of the DevOps movement, the technology profession has seized on the idea that capabilities which were previously siloed and separated should be held by empowered teams with full accountability for what they build and what they run. This is a good idea. The alternative is to have diffuse accountability, degraded quality, teams that communicate with each other by queues and messages, long wait times and fragile systems.
DevOps and the case of the non-fungible DBA
The problem with many traditional, but wrong, ways of organising technology work is that they appear so reasonable.
If you have never organised the work to build a software system before, then it seems reasonable to organise it in the way that you would build a physical building, such as a house or a bridge. You make your plan out of tasks, dependencies and milestones, with blueprints written in advance, planning permission obtained, and predictable estimates for predictable work. Then you wonder why your plans are in pieces, your estimates are blown, and your bridge looks like a cross between a tunnel and a spaceport.
Similarly, if you are defining the operating model for a technology organisation, then it seems reasonable to group scarce, expert resources into pools, so that they can serve multiple needs at the same time. You create all the constructs that go with such a team: ticketing systems, SLAs, queues and prioritisation mechanisms. Then you wonder why everyone is waiting on everybody else, and no-one takes accountability when things go wrong.
Have we overloaded the term ‘technical debt’?
What do we mean by technical debt?
These days, we seem to mean a lot more than Ward Cunningham did when he first coined the term in 1992. As Cunningham has helpfully clarified, he was specifically referring to coding choices made in the absence of full information - information that could only be gained by releasing a version of the code and learning how it was used. The technical debt incurred in this way could be paid down by refactoring the code as its full feature set became apparent - or could be ignored, at the risk that, just as with financial debt, servicing the debt would become all-consuming: developers would spend all their time navigating an ever more complex code base, full of incrementally added and contradictory concepts.
Thinking at lightspeed
Some science fiction writers ignore relativity and don’t treat the speed of light as an absolute limit. This is understandable from a narrative perspective: it allows them to tell stories spanning many worlds, in which fleets of space ships flit across the galaxy, and in which events that happen on one planet can meaningfully be said to happen at the same time as events on another planets.
However, I think that some of the more interesting stories are those which use the concept of relativity and the weird effects it produces. By allowing their fictional vessels to accelerate to near, but not beyond, the speed of light, they create stories in which time moves differently for different characters. In such stories, a character who travels a lot may live a normal human lifetime while millenia pass on the places they visit, and events ripple across the galaxy in lightspeed jumps.
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.