Why Upgrades Aren’t Always Easy – The Horrors of Components

The software component market is great. If you’re trying to make an application, that needs a particular feature, you can often just buy a component that gives you that feature. In addition to buying a component you have other choices.

  1. Build it yourself
  2. Rely on the operating system or language support libraries
  3. Try and find an open source solution

#2 is OK if it’s there.

#3 is fine as long as it’s current and not abandonware.

#1 is usually only if you can afford the development or there is no other choice.

Buying or licensing a component is often the right solution and is often the cheapest thing short and long term because your time is spent integrating a technology not learning it, implementing it, debugging it and integrating it.

The problem that unfortunately comes up is the “can’t go forward, can’t go back” issue. I’ll give you an example of this. This did not actually happen – what actually happened is far worse, but it’s close enough.

At my last job, I created a general PDF library for manipulation and generation of PDF documents. One use of this was that I created an add-on to our OCR product line that let you create PDF documents with each page containing the original scanned image as well as the recognized text which was invisible so when it was highlighted, it made it look like the scanned text was selected. The quality of the output was typically better than that those bundled with OCR engines and it cost less and worked with all engines.

We had several customers who used it and were happy. The initial version had a page limit due to a bug, so I fixed that a few years later. By that time, the original OCR engine we licensed and sold was no longer in our product line and we weren’t allowed to sell it anymore. It had even lapsed from our nightly builds.

And a customer called up and needed more pages than we could offer. The problem was that the new PDF code, modular though it was, couldn’t just be put into the old version. It wasn’t compatible because of OS/language component changes. I couldn’t go backwards. We offered the customer a different engine running on our current version. Nope – because of other component dependencies, they couldn’t go forward. Great.

Because we were a customer-focused company, we ended up doing was figuring out how to get the new PDF code built in a way that it would work with their build, as is. It was a pain in the ass and fortunately, it was just a “one off” so the customer was happy.

Now consider all the machines running custom software with Windows XP that were recently affected by a worm that exploits a security flaw. In fact, I saw a system that runs image analysis on 3D dental x-ray pictures two weeks ago at my dentist’s office that still runs XP. Why? Almost assuredly it’s due to a “can’t go forward, can’t go back” problem similar to what I outlined above.

Why do these problems happen? Sometimes it’s because a component provider no longer supports an older product on a newer operating system. Sometimes it’s because a component provider has gone out of business. Sometimes it’s because a component depended on a bug in the operating system to function. Sometimes it’s because it costs too much to upgrade.

How can we minimize this kind of problem?

  1. Select component suppliers with solid support and a contract that spells out how long the component will be kept up to date and a good bug-fix policy.
  2. Select only components that are supported for the project lifespan of your product.
  3. When budgeting a project, require that there is a line item for operating system/software upgrades including field service.
  4. Consider a requirement that all source and build systems go into escrow.
  5. Include a system replacement clause in the event that a “can’t go forward, can’t go back” problem comes up before the end of the contract terms with training if need be.
  6. If you’re building the component, for the love of all things holy, don’t rely on OS bugs or undocumented features.

And if you are buying such a system, make sure that your vendor can do all these things. If you go with a low-ball contract that doesn’t include these things, then you are risking a much higher cost in the future – either for new hardware or for new software or both. If you can’t plan to pay for that from the beginning, how will you pay for it in a crisis?

One thought on “Why Upgrades Aren’t Always Easy – The Horrors of Components”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.