- 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
Three reasons to learn to code
There’s no point in learning to code: In a few years’ time, we won’t need programmers any more.
I’ve heard people say that a lot in the last couple of years. But that’s nothing new: I’ve heard people say this every year throughout a long career in technology.
On my very first day in my very first paid programming job, I was told that we wouldn’t need programmers any more, because fourth generation languages (4GLs) would enable us to express user requirements in a structured way. In that case, ‘expressing user requirements in a structured way’ turned out to mean using clumsy abstractions that needed to be supplemented with code. Thirty years later, that particular 4GL is forgotten, but we still produce billions of lines of code.
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.
In software, use is better than reuse
If I drink from a plastic bottle of water, and put the bottle in the recycling bin when it is empty, the plastic in the bottle can be used again. This reduces the impact on the environment, but requires a process to collect the bin, sort the contents, process them, and insert any reclaimed materials back into the supply chain.
By contrast, if I drink water from a glass, then I can simply wash it up and put it back in the cupboard. And it is there when I want another drink of water.
This is the difference between reuse and use.
Reuse is a frequently stated goal of technology strategies and architectures. It makes intuitive sense. We spend a lot of money building and buying technology solutions. Different parts of our organisation have similar needs: why not reuse the solutions in more than one place? Some architecture teams even have goals and metrics to measure and encourage reuse. (Like many examples in these articles, this is a mistake that I have made more than once.)
Who puts the V in your MVP?
We’ve been doing it since before the beginning.
In 1943 Donald Michie and Jack Good were working at Bletchley Park on a machine known as the Heath Robinson, after the cartoonist who drew outlandish contraptions. They were attempting to break the Lorenz cypher used by the German high command, an even greater challenge than the Enigma cypher broken by the team which included Alan Turing.
The machine was known as a Heath Robinson because of its complex and unlikely appearance: paper tapes running at high speed around an apparatus called a ‘bedstead’, connected to a maze of wires, mechanical relays and, crucially, a few electronic valves. Getting the Heath Robinson to work reliably was an enormous challenge - such a challenge that it led to the creation of the Colossus, the first digital computer, by Tommy Flowers and team.
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