Title: Editorial: A Mutual Understanding

Author: Martin Moene

Date: 09 January 2015 21:32:36 +00:00 or Fri, 09 January 2015 21:32:36 +00:00

Summary: 

Body: 

I was recently watching a television program about one of Britain’s oldest cathedrals – Canterbury. Part of the program was dedicated to some serious repair work needed after some stone fell away from a high window. No-one was hurt (apparently), but investigations by the masonry experts revealed that this window had previously undergone refurbishment to strengthen it some centuries ago.

That historical repair had introduced a metal support into the stone which had the effect (at the time) of preventing further damage to the structure, and allowed repairs to be made. It also had the unintended side-effect of directly causing the damage hundreds of years later! As I understand it, the metal had flexed during a period of exceptionally warm weather, and split the stonework causing a serious fracture. I’m sure I don’t need to draw a diagram to illustrate the parallels with modern software development: how often have you visited a piece of code and some part of it has made you say (perhaps only to yourself...) “What muppet wrote this rubbish?”

In the case of Canterbury Cathedral, the modern stone masons recognised that those historical refurbishers were operating on the best knowledge of the time, and probably had not considered that their work would even be standing centuries later, much less be the cause of new problems. The same is true of our own forebears in code, those plucky pioneers who dreamed it up, or the generations of intrepid adventurers who’ve fixed it, updated it, squeezed new performance out of it, bent it to new purpose over time. ‘They’ may even have been ‘You’ in those times (and yes, I’ve looked back at my own code and wondered at my own imbecility), and were themselves operating under their own best knowledge and intentions, and almost certainly oblivious of the potential longevity of their inventions.

We all – I think – believe in some way that the best of our code will live a long and fruitful existence and be easily updated and maintained in the future, but I don’t think we generally put as much imagination into exactly what that might entail. And besides, we can’t know what future techniques and methods will be commonplace to our successors, given how difficult predicting the future is.

And so, we are left only with the hope that those successors think kindly of us – as the modern stone masons at Canterbury were most impressed by the ingenuity of their own antecedents – and understand the constraints and limitations of our endeavours. Of course, we should be similarly forgiving of our own programming ancestors, rather than just referring to them as ‘muppets’!

Notes: 

More fields may be available via dynamicdata ..