It can be tempting to retrofit an older solution to add new technology or features. But just because you can make the jerry-rigged contraption work doesn’t mean it’s a good idea. Herewith: a few examples that went Oh So Wrong when someone tried to “duct tape” old technology for new uses – and the lessons for your business.
“If it works, don’t fix it” is a worthy adage. And sure: As long as things stay the same, your IT budget doesn’t need to make room for a new version of the technology on which the business relies. Thus every major system upgrade, shiny new mobile technology, or change in enterprise software is scrutinized before the executive office says, “Sure, let’s spend the money on that – and change the way the users work, too!”
But in technology, how long do things really stay the same?
Thus, we see people try to stretch out the useful lifetime of old technology for as long as they can, and to “make do” in a way that they should not do.
Sometimes the results are, shall we say, less ideal than desired.
That’s one way to make a limousine.
The dealership wanted how much for the air-conditioning option?!
There’s nothing wrong with do-it-yourself!
Sheesh, there’s no reason to spend money on a Bluetooth headset!
Okay, those made us giggle too. But in the business world, the effort we take to keep something old-and-familiar going often costs more (in staff time, at least) than it does to buy the new technology that takes advantage of current platforms.
Refactoring goes just so far. Sure, you can improve current software (and sometimes hardware). But at some point you realize you’re trying to create something new on an old foundation. Retrofitting the solution doesn’t really solve the old problem anymore. The old foundation eventually crumbles under the weight of new requirements, and it doesn’t support the new needs.
Plus, retrofitting keeps you from noticing that the “old problem” was already replaced by a new one. By the time you do recognize the technology shift, your company – and your IT department – is out of date. Then it’s expensive to catch up… if you even can.
That happens to vendors, too. Case in point: WordPerfect Corporation. Once, WordPerfect owned the word processing market on MS-DOS. But when the rest of the industry moved to graphic user interfaces – OS/2, Windows, Macintosh – the company was late to the game.
In a way, WordPerfect’s own DOS success became the barrier to moving forward. As WordPerfect’s then-VP Pete Petersen wrote in his book, Almost Perfect:
[W]e waited too long to add new programmers to the project, always thinking we were so close to a release that we did not have time to train additional programmers and get any significant help from them. We also took too long to make our experienced DOS programmers get involved. They could have helped a little more, but we had a hard time convincing them that the Windows project was more important than anything else. With sales still going up, many thought things were going too well to be concerned.
Worse: The software design was faulty even if “worked” (that is, was reasonably bug-free). WordPerfect for Windows wasn’t Windows; and it wasn’t WordPerfect. That is, the software didn’t match Windows users’ expectations; and the unfamiliar user interface startled the longtime WordPerfect users (who kept using their DOS versions for years).
This applies to today, too, not only to desktop productivity applications from 20 years ago.
When software tacks on new features as an afterthought – not designed for a new environment or current use case – those features never work ideally. Naturally, my primary context is backup software, but the message applies elsewhere, too.
To get specific to enterprise IT: You may be tempted to use existing desktop or server backup solutions to solve your endpoint backup needs. But, as with many retrofitting ideas, sometimes they are only good in concept.
Many legacy backup solutions were designed for a desktop PC world, where people rarely took a computer to a conference room, much less to a coffee shop. The software’s designers made assumptions about bandwidth, latency, recovery protocols, and fixed device location which do not take endpoint backup requirements into consideration.
When that code was written, they didn’t need to think about those things. But to “update” the legacy backup application, features for laptops and mobile devices were an afterthought. The integrity of the design was broken. Software originally designed for the highly predictive environments of desktop and server backup (including a secure high-bandwidth LAN and backups on a regular schedule) perform poorly when confronted with highly unpredictable mobile backup environments.
And users notice. The end result is end users frequently disengaging backup software when the process interferes with their ability to work. That isn’t rare; 51% of end users consider their current backup solution to be intrusive (see: Ponemon Institute: Quantifying the Benefits of Unified Endpoint Data Management).
Instead: If your company relies on mobile devices and the cloud, use software designed for the mobile devices and for the cloud.
Today, end users have the same expectations of enterprise software as they do for consumer software, so ease-of-use and zero impact to productivity should be priorities as you look at alternatives to your legacy backup solution.