Friday, August 27, 2010

It Takes a Licking and Keeps on Ticking

A good friend of mine was making fun of my watch - it’s a basic model, with numbers on the face, a leather strap and a crown/stem to wind it up. Yes, that’s right, my watch does not have a battery, it's the old fashioned spring-driven kind that needs to be wound.

My friend, we’ll just call him Mr. GottaHaveTheNewStuff, created far too much entertainment at my expense over the ancient nature of my time piece - a device I might add that has not made a single unfavorable comment about him.

“When you bought the watch, did they chisel you a receipt or use parchment?” “Do you tighten the spring with a hand crank?” har dee har har, and on and on.

I'd like you to know that my watch is a family heirloom handed down to me from my grandfather who was Sergeant in World War I, and who’s very life was saved on the battlefield by that watch - which means that had it not been for the watch, I would not exist. None of this is true, but I'd like you to believe it.

No, my watch is a $10.00 Timex purchased at a Revco about 30 years ago. I have replaced the strap twice, and had the stem fixed at a mall kiosk in ‘95.

But it works. Mr. GottaHave reminds me that both Revco and Timex Corporation are now defunct (Timex was actually restructured) and so my watch is COMPLETELY out of support, antiquated, and ugly - unlike his iPhone which is fully supported and provides accurate time (to the second) regardless of continent - and looks really cool.

At some point the watch will cease to fulfill the function for which it was purchased; maybe it will break, or maybe it’ll be superfluous with the other gadgets I carry.

The same could be said of our VisualBasic applications. I know that as an architect, and someone who loves new technology, I should be all chagrin over the presence of VB6 applications within our domain. Frankly, as long as they’re still providing value, I’m not sure we need to aggressively replace them.

Yes, Microsoft dropped support an eon ago, the developer tools and the runtimes squeak when loaded, and that acknowledging you have them in your inventory is like admitting you sleep with a Teddy Bear. "What, you have a what?"

Most applications have a life span of a few years; some will surpass that significantly, but most will die on their own terms because the business function they support either changes, gets absorbed into something else, or just goes away. Software is frequently depreciated over three years - so that should provide some insight into the longevity of most applications.

Now, torturing this analogy a little longer, I'm not suggesting that anybody go out and buy a 30 year old watch, or that any watchmaker build a stem-based, spring driven timepiece - i.e. building or enhancing a VB6 application is a bad idea in 2010, but so is replacing technology that is providing value.

If you have a VB6 application that is providing a critical function and is being actively enhanced or sits on workstations outside your control - you should be replacing it. Otherwise, wind the stem, be gentle with the strap, and let time take its course.


  1. Well said, Mr. Chief Architect.
    That is sound advice.

  2. "If it's not broke, don't fix it" is the hardest lesson I've seen junior devs try to learn... and every now and again, you find a senior dev who still hasn't learned it.

    Not learning that lesson is why Netscape let IE eat it's lunch; they went for a complete rewrite somewhere around Netscape 4, and never did catch back up as a company; it was only when an open source fork - Firefox - did really, really well that they caught up much at all. Full rewrites of working software are bad choices.

    Then again, budgeting time to incremental refactoring and replacement is what makes you stable and sustainable, long-term.


Follow by Email