For any Python fans out there you’ll be well aware of the ‘Bring out yer Dead’ scene from the Holy Grail film and this particular blog draws heavily on that sketch for its inspiration. For anyone not familiar with the genius that is Monty Python the scene shows London in around 1665, the populace gripped in the full throes of bubonic plague. Eric Idle is pushing a death cart through the streets yelling ‘Bring out yer dead’. A few residents dump their less fortunate relatives onto the pile of now deceased bodies before John Cleese tries to offload his very much alive grandfather for the full ninepence. Despite the remonstrations from the clearly far from dead old man they eventually come to an agreement, knocking the old man unconscious into the bargain. Nobody expects corpses to have so much to say.
Now, I hear you all say, where on earth are you going with this Mr Salopian? What flight of fantasy are you going to take to equate this medieval scene to 21st century software? How tenuous will this link be?! As it turns out, not very tenuous at all. I am currently in the process of revisiting a software solution that a colleague of mine developed in 2006, not that long ago really but in terms of software (certainly in the eyes of Apple) we can almost regard it as vintage. The development ecosystem at this time was very different, we were looking at .NET 1.1 – 2.0 and a lot of the component vendors had just put a shim over their existing COM libraries in order to get to market in this newly evolving world of .NET.
I remember clearly, just a few years earlier, the conversation that our small team had abandoning our existing development stack in favour of this the .NET fan-dangled thing. The move at that time seemed gargantuan, now it seems a no brainer. At the time it meant redeveloping all of our live software using a proper language. It also meant leaving my boss at that time behind as he could not adapt to the new language and on numerous occasions he got quite frustrated with the lack of control he now had over the coal face of the code. This conversation was no long drawn out thing, in fact we were standing up next to my desk when the decision was made. Overnight the tools of the company changed, the very next day we consigned VB6 and Delphi to our history and we started from scratch. We took our living applications and rebuilt them (putting the older, but still functional, incarnations on death row as we did so). For a period of time the doomed applications kicked and screamed and generally did the jobs that they were meant to until over time the new shiny replacements went live. What we had done was the software equivalent of battering Grandpa over the head and paying our ninepence; it stood our applications in good stead for the future.
The problem with this approach is that not every contract affords you this luxury or indeed even if it does rarely do we do it. Generally we work on a very ad hoc basis, refactoring when required, more often than not heavily restrained by the decisions of the past. Each refactor gently tightens the noose as the refactor tends to be for new functionality only and not to take best advantage of the tooling available. And this is the problem, not taking advantage of the ‘latest and greatest’ over time is a false economy. It doesn’t push you as a developer and it makes life harder on the software. It is the age old battle between evolution and revolution writ large.
I am currently in the process of refactoring some code created again around 2006, I think it would be safe to say that right now evolution is not an option on the table. I’m just paying my ninepence and turning a blind eye to the death blow being dealt. Looking forward I can see that in managing our long term projects we need to be much more proactive in pushing out the latest tooling and keeping abreast of the changes in the Eco-system. Not change for changes sake, but change because it is inevitable.