An Obligation to Improve

From 1983 to 2014I 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.

This entry was posted in Computing, Software Development and tagged by Stan York. Bookmark the permalink.

About Stan York

Stan York (VP of Development at Spitfire) has been developing software for decades. Which means he's old enough to remember when punched cards where the state of the art UI. Stan makes no secret about the fact he often prefers data to people, so it should come as no surprise that he is an expert in databases and SQL server. If asked, he might admit he is an MCP, because he knows this is important to some people, particularly at Microsoft. The postings on this site are his own and don’t necessarily represent Spitfire's positions, strategies or opinions.

One thought on “An Obligation to Improve

  1. I never looked at it that way before but you are right. In our field things “break” just by getting old. I’m pretty sure 100% of the software I developed during my career is no longer in use because it has been replaced by better options not because it was poorly designed or written for its time.

Leave a Reply

Your email address will not be published.