Bridges and Airports
This story is not my own. It was first told to me sometime in the late 1980s by Nat Lunn, one of the senior managers at my first “real” developer job, and rightly it belongs to him. I’ve completely fictionalised it for the sake of making a more entertaining story, but the underlying wisdom comes from Nat. Mistakes, omissions or misrememberings in the telling are my own error.
Despite his C-Suite seniority, Nat remained deeply connected with the technical side of the business, and completely untouched by the ego-diseases that so frequently afflict people at those lofty organisational altitudes. He was happy to engage even the most junior members in the (quite large) organisation in bouncing around ideas and experiences, not merely sharing his wisdom, but encouraging us to cultivate our own.
Bear in mind that the tech backdrop to the conversation would have been grounded in the realities of the early 1980s: IBM still ruled the world (though they were soon to fall from grace), relational databases were a novelty, still nearly a toy, the only network was the IBM terminal network, and most code was still Cobol or Assembler. (And it was just “Assembler” — no need to specify “IBM Mainframe Assembler” — that would be taken as read.)
Bridges and Airports
It was on a camping holiday with a very old friend, Dave, that I came to see clearly, that there are two fundamentally different views of the world of software, that confusion or disagreement in discussion between experienced and otherwise quite reasonable software designers frequently stems from this difference, and their ignorance of its existence.
Dave and I were cracking a beer or two around the campfire after a hard day’s hike when talk turned, as it will, to the shared ground of making software. Dave was telling me some war-story about a project he’d been on, with all the usual hair-raising twist and turns and mysterious heisenbugs we’ve all experienced, but in the end all turned out well. He made the appropriate changes in the code, and then…
‘We rebuilt the system.’
This phrase, ‘rebuild the system’ — which Dave used quite often — was peculiar to me, at odds with my own experience.
In my world, there is no one “system” that we can rebuild. At most you would recompile a programme and, after some testing, put it into production alongside all the other programmes. Dave’s world was that of control systems. Mine was that of enterprise data.
I came, later, to call these two — vastly different — environments, the Bridges and Airports Worlds.
In Dave’s world, the Bridges World, almost all of the complexity in the software lies in the code itself. The data is usually trivial, almost incidental.
In my world, the Airports World, the programmes are usually quite simple, usually being simple CRUD applications or report extractors that float atop an immensely complicated and deeply intertwined database whose structure has evolved over years or decades. The complexity is all in the data.
In the Bridges World, software either WORKS or is BROKEN — not working — without much leeway between the two states. In the physical world of roads and railways, if you build a bridge that’s a metre too short, it’s a failure. It cannot be used and is unfit for purpose until you fix it and bridge that final gap.
In the Airports World, some subset of the software is ALWAYS broken: nominally working, but not 100% correctly. Deficient and imperfect, but nevertheless GOOD ENOUGH to be getting on with. Good enough for the enterprise to carry on doing business despite the fact the people have to do some odd things to work around the annoyances of imperfect programmes. Eventually someone might get around to fixing some of the grosser deficiencies.
If a bridge ages poorly, degradation unabated through preventive maintenance, it will eventually become unsound, at which point one’s only choices are to stop using it altogether, or to carry out some heroic restorative rebuilding and reinforcing, or to build a new bridge altogether. Very much an all-or-nothing proposition and with budgetary demands to match.
Think of an airport. When last were you in an airport where there was NO construction work going on? No gates shut for refurbishment? No part of the terminal buildings (or apron or hangars or baggage handling or fuel-delivery) walled off with shutterboard and a sign telling you that “The New Facility Will Be Opening Soon. We Apologise For The Inconvenience.” It’s almost impossible to imagine such an airport. And yet the airport continues to operate regardless. It has to.
If a Bridges World software system has to be shut down for any reason, you hand over its functions to a backup or standby system until you can restore it to operation.
In the Airports World there is no such thing as a backup airport. You simply have to work around the 24x7 operations while you dig holes in the tarmac and repair, augment or replace the pieces. And then you go on to replace/fix the next piece. The enterprise never stops working. It can’t.
[Mike again.] I’ve long found Nat’s “Bridges and Airports” story a useful thing to keep in mind when I hear a developer (or dev manager) expounding on The Right Way to do something. It helps greatly to understand which of the worlds they live in/come from as the context for their strongly-held belief.