- agents
- AI
- ambiguity
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- compliance
- corporate life
- data
- decisions
- delivery
- devops
- disagreement
- end user tools
- ethics
- failure
- fear
- fundamentals
- government
- halloween
- history
- humans
- hype
- identity
- inclusion
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- privacy
- process
- procurement
- products
- programming
- quantum
- reliability
- resilience
- risk
- science fiction
- security
- shadow IT
- space
- strategy
- talent
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Please pay attention to the safety briefing
What do you do when the air crew ask you to put down your books or devices and pay attention to the safety briefing? Do you follow their advice, because this aircraft may be different to those you have flown on before? Do you study the safety card when the briefing is over? Do you check that you know the location of the life jacket, under your seat or in the compartment next to you? Or do you zone out, diving deeper into the mental limbo that air travel induces, waiting for the moment when you can start reading, scrolling or checking emails again?
I expect that most of us regard the safety briefing as a dull but worthy formality, and don’t pay as much attention as we should. However, I also think that perhaps we should regard it differently, and learn some lessons about how we achieve safety in enterprise technology.
The change *is* the system
What do you think of when you think of computer systems? Do you think of a fixed set of features and functions, designed to meet a particular purpose, which changes steadily over time as a result of planned projects or essential maintenance? Or do you think of a dynamic process of continuous change, which adapts to meet a set of needs and opportunities revealed through practice and experience?
Many people who have worked in systems development for a while would favour the second definition: they recognise that a computer system is never ‘done’ and that its capacity for change is one of its most essential features. However, most organisations continue to construct investment plans, portfolios and even balance sheets as if the first definition was correct: IT systems are fixed assets with defined purposes which are built through upfront investment and then depreciated over time.
I was going to do something about legacy technology but I forgot . . .
Have you ever had the weird experience of reading a book and, part way through, realising that you’ve read it before?
Or being recommended a book, going to buy it, and realise that it’s already on your e-reader, marked as read?
Human memory is strange and fallible. It seems that it is possible for us to spend hours engrossed in an activity which occupies our minds, and then completely forget about it.
Do your approvals processes make it easier to do nothing than to do something?
Have you ever seen a project plan which is a victim of the approvals process?
You can usually tell when a plan has suffered in this way. There may be long gaps when nothing is happening, followed by frantic activity around a monthly or quarterly date. Or there may be design and planning work which is crammed into the plan far too early, in order to hit an approvals board. There may even be a whole part of the plan – and the team – dedicated to gathering data and writing requests for approval.
Technology people seem to hate approvals and love them at the same time. Nobody enjoys navigating their way through complicated and arcane processes where every signpost says, ‘Not this way,’ or ‘Try again.’ And yet we don’t seem to be able to stop ourselves from creating more processes: approvals to purchase, approvals to hire, approvals to release, approvals to change, and approvals to change the approvals process. I've certainly been guilty of implementing processes which seemed like a good idea at the time, but less so in practice.
All the things that matter still matter, but they matter more
Hype tends to be, well, hyperbolic.
If you read headlines and social media posts about the use of AI in software development, then you would be forgiven for thinking that is the end of everything. No more developers! No more testers! No more SaaS! English is the only coding language! The death of technologies, practices and industries has been declared many times over the last few years - and yet they seem to keep on going.
If we step away from the hype and take a few deep breaths, I believe that we can see that, while AI will have a disruptive impact on software development, it will be one of amplification rather than dislocation.
How I stopped fearing the phrase, ‘I’m not technical.’
My heart used to sink when I heard someone say, ‘I’m not technical’.
Not because I think that everyone in the world should be a technical expert, but because those words were usually said by a digital leader to mean that, although they were in charge, they didn’t actually understand most of what their team did every day.
Sometimes the phrase was used to indicate humility: ‘I don’t have a technical background, so you’re going to have to explain things to me.’ But at other times it indicated a lack of interest: ‘I haven’t got time for all this technical nonsense – just get the job done.’ (You can imagine which I was most pleased to hear.)
Revealing invisible ingenuity
If you are ever in Paris and looking for something to do, then it is worth a visit to the Musée des Arts et Metiers. Don’t be misled by the name: although it translates to ‘Museum of Arts and Crafts’, you won’t find any William Morris wallpaper or Rennie Mackintosh chairs: it is a museum of technology.
What you will find is hall after hall of inventions, models and instruments, from the 18th century to the 21st century, charting the development of technologies that have shaped the world. There are early phonographs and radios, steam engines and looms, suspension bridges and space robots. There is a secret camera built into a hat, the preserved laboratory of Antoine Lavoisier, and Foucault’s pendulum, swinging backwards and forwards from the roof of a church, steadily measuring the rotation of the Earth.
Standing on the edge of uncertainty
The practice of software development is being disrupted.
This might not seem like a new phenomenon. Software development is a practice which seems to be subject to continuous change, in an industry which prizes disruption. Over my own career, I have moved from a world in which code was designed according to heavyweight, structured methods, before being written used bare and basic editors, and tested through intense manual effort, to a world in which code is designed, developed and released in short sprints, written in sophisticated development environments, and tested through an automated pipeline.
However, even though programming is not typing, the activity of writing code has been remarkably stable since the invention of high level languages: assembling logical constructs to make the computer do what you want it to do, and then putting one line after another until you are done. And then debugging it until you are actually done. And then continuously improving it, because you are never really done.
Programming is not typing
What does programming look like?
If you believe films and TV programmes, it looks like typing. In a fraught situation, where the hero’s technical sidekick is attempting to defuse a bomb, or ‘hack into the mainframe’ it looks like typing very fast. If it’s the hero who is doing the programming, it looks like typing very fast while wearing sunglasses. If it’s the villain or one of the villain’s minions, it looks like typing very fast in a room with blacked out windows, possibly surrounded by pizza boxes and other debris.
(In one notorious example from a police procedural programme, it looks like two people typing very fast on the same keyboard at the same time. I have no idea what the actors in this programme thought their characters were doing, and suspect that the scriptwriters didn’t either.)
Reasoning and reflex
I didn’t learn to drive a car until I was in my mid-twenties, and I found it difficult. It took me three attempts to pass my test, and a lot longer before I was a confident driver. But, as well as teaching me how to drive, the experience taught me the difference between reasoning and reflex: the difference between knowing what you should do, and doing it automatically due to muscle memory.
Later, I learnt the management lesson that, when we acquire new skills, especially those with a physical component, we pass through phases of unconscious incompetence (we don’t know what to do), conscious incompetence (we know what to do but we can’t do it), conscious competence (we know what to do, and we can do it when we think about it), and unconscious competence (we know what to do, and we do it automatically).
AI - a catch up guide to early episodes
Have you ever tried to start a major TV series partway through? You hear everybody talking about it at work, and it sounds thrilling. Then you watch the latest episode, and are baffled by names, places and relationships. Why is this woman so angry with that man? Why are those two factions fighting? And why are those people wandering in the wilderness, apparently disconnected from the rest of the plot? You switch to the series guide on your streaming service and realise that, to catch up, you are going to have to watch the three previous seasons. Perhaps you should just watch that cooking show again.
Trying to understand AI can feel like this. To many people, the appearance of generative AI a few years ago was a sudden, magic and unheralded event, followed by a never ending stream of releases, products and announcements. It’s hard to make sense of the present, let alone look to the future.
Your Moonshot doesn’t have to be a Moonshot
In 1962, NASA faced a difficult technology procurement choice.
They needed a guidance computer for the Apollo Moon missions. Did they go for a design based on new technology, working with researchers at MIT, or a design based on proven technology from their existing suppliers?
They chose the new technology: rather than discrete electronic transistors, they would use silicon chips, which combined multiple transistors into a single component. These chips weren’t like the chips of today, though: rather than millions or billions of transistors, they contained just a few transistors, each representing a single logic gate. Thousands of them were needed to build the Apollo Guidance Computer (AGC).