I remember when I was fresh out of college, Bill (one of the programmers with many years of experience), tried to teach me a life lesson: “if it ain’t broke, don’t fix it.” I understood his point, but also recognized a danger in that philosophy. In perspective, according to Wikipedia, that saying became popular only in 1977. There is evidence of the counter argument at least 1900 years earlier in a Bible story in which a dude who buries his boss’s assets (the ultimate digging in) is called wicked and lazy because he failed to improve the asset.
Given these opposing pulls, I should not be surprised when I discover a system that is still running the RTM version of SQL 2008 (which should have had Service Pack 3 applied in late 2011). But I am somewhat disappointed. I understand the conflict, but there must be a balance.
I was recently pleased to learn that software I wrote 20 years ago was still in use, then just as quickly horrified to discover the screen layouts I had been forced to cram into a 640×480 space had never been updated by the staff that took over that code base. I have used both of the computing systems pictured above–and I was as thrilled when I got that Compaq as when I got the Dell XPS 18. But I didn’t stay with the Compaq for too long.
In my field of technology:
- the definition of what works and what is broken changes over time.
- what seems to me to ‘work’ may in fact have hidden issues (security, usability or suitability).
- if it isn’t generating productivity, it is already broken.
So here is how I balance this equation. The actual purpose of deployed technology is to improve total system efficiency (which minimizes long term, ongoing cost). If greater efficiency is achievable at a sufficiently reasonable investment, then it is my obligation to pursue those improvements. The cost/risk/benefit of improving screen layouts as screen resolution increased should have been a no-brainer.
Given that change is inevitable, I gain control by making changes regularly and in a timely fashion. Even by applying a service pack in a timely fashion, I learn right away what it changes for better or worse, and can make adjustments as necessary. And my foundation ultimately stays as sound as it can.
Well, Bill, now you know what I did with that life lesson. Hopefully, Spitfire’s clients will appreciate the changes coming in our next version of the Spitfire Project Management System this August.Tweet