- 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
Return of the spec
How much thinking do you need to do before you start coding?
When I got my first professional programming job, back in the late 1980s, the answer seemed to be all the thinking. We were encouraged - no, obliged - to use a method known as Structured Systems Analysis and Design Method, or SSADM, developed by the UK government. It was the very definition of a Big Upfront Design method, where you had to write multiple layers of specifications, accompanied by a whole array of models which described data structures, data flows and the lift history of data items (it was a very data-oriented method), before you even thought about writing a line of code.
What does 'architectural significance' mean in the age of AI?
When is a decision architecturally significant?
This question has vexed all of the technology architecture teams and governance structures which I have attempted to set up in my career. The thinking goes something like this: technology is complex and difficult, and we seem to have made some bad choices in the past; it would be a good idea if we were more thoughtful about our choices, and spent time trying to get them right; we could do that through some sort of governance process; however, if we subject every single decision to that governance process, we will erode autonomy and slow everything down; let’s focus our governance process on decisions which are architecturally significant, and let all other decisions be taken locally.
Technology architects aren't vampires: they don't need to be invited in
Vampires are puzzling. They have all sorts of rules which help make dramatic stories and films, but which don’t make much sense if you stop to think about them. For example, consider the rule that vampires can’t enter a house unless they have been invited in. Does it matter if the inviter lives at the house or not? What if the vampire receives a party invitation in the post? Is it okay if they are the +1 rather than invitee? Does a ‘Welcome’ mat work? It’s probably best for us not to ask too many questions, but just to accept the rules and enjoy the story. Oh no! The protagonist has blithely invited the monster in for a cup of tea!
However, while this seems strange in fiction, we often encounter its equivalent in real life, especially if we work in the technology department.
There's always a bigger goat: don't let big problems stop you solving smaller problems
In the story of the three billy goats gruff, the goats want to cross a bridge guarded by a troll. They manage this by each telling the troll that there is a bigger goat just behind them until (spoiler alert!) the biggest goat comes along and butts the troll into the sky.
Sometimes, when we are trying to make the case for enterprise technology capabilities, it feels like we are the trolls, and that we are so scared of the biggest billy goat that we won’t tackle the smaller goats. When we look across our technology landscapes, we see mess, waste and mayhem, and wish that we had some of the foundational capabilities that would help clean things up. Yet we hesitate, because we know that every time we build something we will uncover another problem, and another problem, and another problem, until we get to problems that are so big that we cannot imagine how to solve them.
It’s more complicated on the inside than it is on the outside
We don’t need time machines to create paradoxes in technology: they are built into the way we work. One of these paradoxes is that the simpler technology appears on the outside, the more complicated it is on the inside.
I was reminded of this recently when talking to someone who confidently told me that the more sophisticated AI models get, the easier they will be to use, for technologists as well as end users. AI would solve its own skills problem. I was surprised by this because, to me (and, I expect to most other technologists), while we understand how natural language interfaces can radically simplify the experience for end users, the introduction of the current wave of AI into our architecture makes it more complicated.
Build systems like you hire teams
Despite advances in AI, software systems are not people. But perhaps we should sometimes treat them like people - at least when it comes to budgets and financing.
A couple of weeks ago, I claimed that building software is not like building a bridge, and that the analogy of construction which we use - which I use - so frequently, may be harmful rather than helpful. Rather less usefully, I also suggested that there aren’t any perfect analogies, and that the best way to think about building software is to understand the business of building software. I’m now going to contradict myself and suggest another analogy: that we should think about building software in the same way that we think about hiring teams.
Good standards are like a good starting word in Wordle
What’s your starting word in Wordle?
I use STEAM. It has a good combination of common vowels and common consonants, and for some reason I find it pleasing (something to do with steam engines?). There are words which are mathematically proven to be better, but I like this one.
In case you’re one of the few people who didn’t become familiar with Wordle during the pandemic, I should explain. It’s an online game where you have six attempts to guess a five letter word, and each letter in the guess is marked green, for a correct letter in the correct place, yellow, for a correct letter in the wrong place, or grey for a letter which is not in the word at all. It’s just about hard enough to give you a sense of achievement, but easy enough that you get the right word most of the time. It also has the virtue that everyone who plays the game worldwide gets the same word every day, making it feel as if you are all playing together - you can also share your pattern of green, yellow and grey without giving the game away.
Freedom is not free: managing your cognitive and operational economies
Freedom is not free.
Let’s unpack that apparently paradoxical phrase into something a bit more unwieldy, but a little clearer.
In the context of enterprise technology, freedom of choice comes with a cognitive and operational price which we must be sure we want to pay.
The question of freedom versus control in enterprise technology has been debated with varying degrees of heat and passion for as long as the field has existed. Centralised corporate IT functions usually like control. They like to be able to manage costs and risks, to limit the complexity of their architecture and their supply chain, to strive for confidence and predictability. By contrast, development teams and product teams typically like freedom. They like to be able to pick the technologies, frameworks and ways of working which suit them best, to innovate freely, to use their skills and express their professional expertise.
Complexity and simplicity are friends
How many applications is too many? 100? 200? 1,000? 7,000?
I have worked for many different organisations with different numbers of applications. Whatever the numbers, though, they all had one thing in common: somebody, somewhere thought that we had too many applications.
I have always found this belief puzzling. We build applications because we believe that they have value (otherwise we wouldn’t put so much effort into writing those business cases). We celebrate our success when we implement them. And then we record their existence in our great big list of applications, lament that we have so many, and wish that we had fewer. Is there any other field of endeavour where what we have built moves so quickly from asset to liability (whatever our accounting rules say)?
I believe that people worry about the number of applications in their estate because of an inherent fear of complexity, and because the number of applications is a visible signal of complexity. They perceive that their technology is becoming too costly, too slow and too risky, and they also see that these factors rise in sync with the number of applications. The more stuff they have, the harder it seems to get
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.
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.