David Knott 28/12/2023 David Knott 28/12/2023

What’s hiding in your technology sock drawer?

If you celebrate Christmas, I hope that you got some good presents. But you may also have got some presents that seem fun for a few weeks, or a few days, or a few hours and that you then put away, never to take out again.

In the fascinating podcast series Gamecraft (https://www.gamecraftpod.com/), Mitch Lasky and Blake Robbins explore the history of the video game industry. I learnt a lot from this series about the economics and history of video games, as well as the way that the behaviour of developers and players has shaped and been shaped by games. I recommend listening to the whole series, but there’s one concept that particularly stuck with me: the idea of ‘sock drawer ware’.

This is consumer technology that appears to be a good idea, and that looks like it will gain a committed, sustained audience, but ends up in the sock drawer after a few weeks. (This term crops up in the episode about virtual reality - sorry VR people, but this seems like a good way to describe the repeated waves of enthusiasm and indifference that have greeted developments in VR. Perhaps this time round it will be different.)

David Knott 21/12/2023 David Knott 21/12/2023

Now you’re thinking with . . .

Christmas is a time for play, so let’s talk about a game. If you haven’t played the video game Portal, then I suggest that you stop reading this article and go and play it.

Welcome back. Did you play Portal 2 as well? If not, go and play that one as well: it’s even better.

If you didn’t take my advice, then you’ve missed out on a great experience. (Maybe you should go and try it - we’ll wait.) I believe that the Portal games are examples of just how good video gaming can be: intriguing, playful, thoughtful and challenging, with a sparse but engaging story.

In the games, you are a subject in a lab, and you have one tool to pass a series of strange and dangerous tests: a portal gun. When fired, this gun creates a hole on a surface, and when fired again, it creates a hole on another surface. If you jump through one hole, you come out of the other - it’s a portal! The games are an exercise in creativity on top of this simple premise, by both the developers and the players.

David Knott 14/12/2023 David Knott 14/12/2023

The lion, the steam train and the LLM

Last week, I was fortunate to go on a journey on a steam train, from one side of England to the other and back again. All along the route, people smiled and waved and took photos as the train chugged past: it was a special sight.

From a purely technical point of view, this happy reaction may seem to make no sense. Steam trains are slower, less reliable and more polluting than their electric alternatives. Yet a steam train has charisma: it has a presence and an energy which an electric train, no matter how sleek or modern, can’t match.

There is an analogue in the world of nature: some animals are deignated charismatic megafauna: lions, tigers, elephants, rhinos and so on. You can probably guess the top ten animals in this category: they are the animals that appear in film and stories, in advertising and environmental campaigns. They have a status as symbols: their images mean courage, ferocity, strength and other abstract concepts which may have little to do with their actual attributes and behaviours.

David Knott 07/12/2023 David Knott 07/12/2023

Eat your standards: they’re good for you

I didn’t like vegetables much when I was growing up.

This might have been due to my immature palate, or it might have been because the quality and variety of vegetables in British cuisine in the 1970s were limited. I knew that I was supposed to eat more vegetables, but why should I when there were plenty of burgers, chips and beans to go around? (Do chips and baked beans count as vegetables? Technically, yes, I suppose, but not aesthetically or nutritionally.)

I think that technologists sometimes have a similar attitude to standards. We know that we should follow them, we know that they are probably good for us, but we also feel that they cramp our style, and that they are rather less fun than they could be. This is especially the case when we have the figures of central governance, change boards and process approvals looming over us, asking us whether we have implemented our standards and whether we can prove it, the technical equivalent of asking whether we have eaten our vegetables and whether we have clean plates to show for it.

David Knott 30/11/2023 David Knott 30/11/2023

Twelve firsts: lessons learnt from a few decades in technology

What have you learnt in your career?

I was privileged to be asked this question by some of my colleagues in the Central Digital and Data Office, in the hope that some of my stumbles, trips, outright failures and occasional successes would provide useful lessons. I’ve worked for about twenty organisations over more than thirty years, so there were a lot of examples to choose from, but twelve firsts stood out for me - things which shaped me when I experienced them for the first time.

The first time I used a computer was a ZX81 which one of my father’s friends had lent us. We only had it for a few days, but it taught me that if I put instructions into the machine, it would do what I told it to do. I’ve carried on putting instructions into machines, either directly or indirectly, ever since.

My first full-time job was in a lab while taking a year off before studying biology. It taught me that I was not cut out for the precision and repetition of lab work, and that maybe this field was not for me. I did like working with the computers that ran the lab equipment, though.

David Knott 23/11/2023 David Knott 23/11/2023

How do we make non-functional requirements exciting?

They’ve got that look again.

If you’re a technology architect, particularly one who designs infrastructure, then you’re used to people getting that look. Their eyes glaze over, their smile becomes fixed. They may have an air of panic. Why is this person talking to me? What’s a server? What is latency, and why are they so worried about it? What’s the quickest way out of this meeting? There’s only one sure way to dispel this look: to start talking about time and money.

Welcome to the conversation about non-functional requirements. This is the time when the technology architect tries to agree with their business sponsor (or, more usually, the business sponsor’s representative) what compromises they will make together. Because there are always compromises: if you ask someone how much downtime they can tolerate, what the response time should be, and how many users the system needs to support, the default (and not unreasonable) answers are likely to be: none, instant, and everybody. Until you explain how much it would cost and how long it would take to achieve those things.

David Knott 16/11/2023 David Knott 16/11/2023

Are we there yet? When can we stop mapping our technology architecture?

In his short story On Exactitude in Science, Jorge Luis Borges writes about a historical Empire so taken with cartography that it makes a map of itself at a 1:1 scale: so big that it covers the territory it describes. Such a map is, of course, useless, and it is allowed to decay into tattered ruins.

This story raises a common question faced by technology architects: when does it make sense to stop mapping?

I believe that the discipline of technology architecture first arose from the desire for a map. Back in the 20th century, when we had been building software for long enough that things were starting to get complicated, but not so long that they were impossible to understand, people realised that it might be a good idea if we had some sort of systematic explanation of how things worked. So, we started modelling and mapping, and building repositories, and producing diagrams, and creating methods, and inventing governance structures, and all the other things that we do to keep us busy.

David Knott 09/11/2023 David Knott 09/11/2023

Five pieces of advice for technical leaders

What advice would you give someone taking on a new technical leadership role? As I wrote a few weeks ago, technical leadership matters, but there are few resources to learn technical leadership, so we have to rely on what we can learn from each other. I’ve been privileged to work with and for some great technical leaders who have been generous with their advice. Fortunately, advice is one of those things which gets more valuable the more you pass it on, so I thought it might be helpful to share a few bits of advice which have helped me.

Don’t panic

In the field of enterprise technology, things go wrong. All the time. If you have an operational role, then you spend much of your time dealing with incidents. If you have a change role, then you spend much of your time dealing with obstacles to delivery. And if you have embraced DevOps (as we all should) then you get to deal with incidents and change obstacles at the same time.

David Knott 02/11/2023 David Knott 02/11/2023

The vicious circle of legacy technology

Where does a vicious circle start?

I think that, in the case of legacy technology, it starts with an implicit agreement: to optimise for short-term outcomes over sustained capability. I also think that, once that implicit agreement gets the vicious circle of legacy technology going, it gets progressively more difficult to stop.

Let’s take a step back, and make it clear what we mean by legacy technology, and what it means to optimise for short-term outcomes.

‘Legacy’ is a euphemism. In normal language, it means something good: the things that we are proud to leave behind. In enterprise technology, it means something bad: the systems that have truly been left behind, in the sense that technology, capability and best practice have all moved on.

David Knott 26/10/2023 David Knott 26/10/2023

How do we get people to care about computing?

‘I’m not technical.’

If you work in enterprise technology, I bet your heart sinks when you hear those words. Whether you hear them from a programme sponsor, the leader of a business unit, a product manager or a project manager, you most likely perceive it as shorthand for, ‘I know that the success of this project depends on technology, and I know that the technology is going to be really complex and difficult, but that’s your problem, not my problem: I’m not going to engage with things that I don’t understand.’

There are a couple of reasons that this sentiment irritates technologists.

The first is practical: it means that, when they hit problems, they are unlikely to get active, engaged, curious, empathetic support - they are more likely to get asked to just fix the problem, to make it cheaper, faster and easier to deliver.

The second is more emotional: many of us work with technology because we find it fascinating and exciting, and we want to bring its potential to the world. We want others to be as fascinated and excited as we are, and the phrase ‘I’m not technical’ typically signals a lack of interest: the door is closed to fascination and excitement.

David Knott 19/10/2023 David Knott 19/10/2023

Technology leadership matters

I believe that the use of technology has an outsized impact on the success of organisations, and that the quality of technical leaders has an outsized impact on the successful use of technology. Organisations which don’t make good use of technology lag their peers, and organisations without great technical leaders struggle to make good use of technology.

This means that technical leadership matters.

However, technical leadership does not seem to be well understood, and there are few resources to help people become great technical leaders. I have held many technical leadership roles in my career, and have been fortunate to have access to some outstanding leadership development and technical training - but have struggled to find help to put technology and leadership together.

As a result, I don’t claim to be a great technical leader: there’s a reason that the title of this newsletter is A Lot to Learn. However, I have worked with and for some great technical leaders, and have picked up a few ideas along the way.

David Knott 12/10/2023 David Knott 12/10/2023

The dawn of a post-legacy world

It’s easy to be fatalistic when you work in enterprise technology.

Of course the great big programme will go wrong: great big programmes always go wrong. Of course the infrastructure will fail: infrastructure always fails. And of course we will always have legacy technology: technology becomes legacy the moment it is deployed.

Sometimes this fatalism is cynical: it is the world weary shrug of people who have lived through many failures. Fortunately, though, this fatalism is more often realistic, practical and active, and prompts us to create mechanisms to deal with inevitable failure.

Great big programmes always go wrong: that’s why we break them up into smaller pieces, manage our work through backlogs, and adjust our plans after each iteration.

Infrastructure always fails: that’s why we design reliability and resilience into our solutions, and treat infrastructure failure as an expected operating condition.

Except for legacy.