I’m David Knott. I’ve been working in enterprise technology for over forty years and I’m still learning. This blog is based on mistakes, failures, lessons and some things I find interesting:
Three sentences that I say too often - and will keep on saying
The longer I spend in leadership roles, the more often I find myself saying the same things over and over again. I expect that part of this is due to intellectual laziness – it’s easier to recycle the same thoughts than to have new thoughts. But part of it is because, over the years, I have found leadership principles that work for me, and words which express them concisely.
There are three things in particular which I say a lot, which my team sometimes tells me that I say too much. None of them are original – they are all ideas which I have learnt from others. They are . . .
A moment in the project plan; a lifetime in the codebase
Software can be a source of regret as well as value. It is a common experience to find yourself looking at code and wondering what fool could possibly have written it, only to read the comments and find out that it was you.
The passage from choice to regret is often clear to developers, despite their faulty memories. You knew what you were doing when you made those decisions – and that you (or someone else) would pay for them in the future.
However, this path is not so clear to other stakeholders and non-technical decision makers – and their choices are often the ones that create the most regret.
Welcome to the age of the puppeteer octopus
What will software development teams look like in the age of AI agents? Will they look much the same as today, with the productivity of each team member incrementally enhanced? Will they be hybrid constructs, comprising human members and AI members? Or will there be no teams, just networks of AI agents talking to each other in the absence of human beings?
As we learn more about the potential and limitations of the current form of AI, I become increasingly convinced that we are entering the age of the puppeteer octopus.
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.)