Temporary fixes that become permanent

If you’ve worked in IT, you’ve seen this: “I’ll just make this patch until someone can do a more elegant solution.” And that temporary fix never gets replaced, because as the old saying goes, “Broken gets fixed, but ‘does the job’ lasts forever.” We asked our community for their stories about a “quick fix” that became a permanent one.

Chris Rigsby shared his experience in writing a fix as a proof of concept:

One morning, my boss appeared in my cubicle, describing a new software-induced political crisis and wondering if I could help. After twenty years, I’ve forgotten the specifics of the issue, but the result still haunts me.

First, I replicated the problem in a development environment. As fast as I could, I hacked together the code equivalent of a MacGyver duct tape, bailing twine, and bubble gum as a proof of concept (POC) only. I was moving fast, putting the word TEMP (and worse, my username) into object names and code as I scrambled to design a demo fix. I fully intended to take an hour to refactor the solution into a more elegant and standards compliant package before shipping it to the functional users for more thorough testing and approval.

Alas, when I demonstrated the POC solution, I heard these terrifying words: “Perfect! Move it to the Test area and notify the customers.” When I replied it would be on its way in about an hour, I had to explain that what I’d just demonstrated was an ugly hack that wouldn’t pass the QA review and needed refinement.

My stomach flipped when I heard the next sentence: “If this fixes the issue, ship it for testing. I’ll talk to the QA people. We’ll patch it in the next quarterly release.”

Sadly, I never got to patch things up and as far as I know, the poorly named objects are still in production today. Lesson learned: never use TEMP, TMP, or your username in widget, table, or code object names.

Byron Patterson used a misspelling in a URL for testing, but it stuck around forever:

Misspelling “subscription” as “subskripshun” so it would be unique and never used intentionally to build a list of courses included in an unlimited subscription a company could buy. Still in use today. The website URL looks like https://example.com/SearchResults.aspx?searchterm=subskripshun

David Both wrote a backup script that he never got around to replacing:

Over the more than forty years I’ve had one or more computers in my home, there’s always been the need for backups. Before I found Linux I used several expensive backup programs that relied on tape drives which were far less reliable than I would have liked. In fact, I was never able to restore from tape when necessary. To make matters worse, every time a tape drive died, the technology had changed so a replacement drive also required replacing all of the expensive tapes as well.

When I started using Linux in 1996, I had an unusable tape drive and tapes that were unreadable. I needed a new approach to backups.

Since my experiences with external USB hard drives was excellent, I decided to use them as my backup medium. All I needed was a program. I tried some open source backup programs and, although they worked well, they weren’t really what I wanted in a backup program.

Way back in 2009 I had been experimenting with the rsync command, which has some very interesting features that I have been able to use to good advantage. My primary objectives were to create backups from which users could locate and restore files quickly without having to extract data from a backup tarball and to reduce the amount of time taken to create the backups. I planned to use this tool until I could find open source software available that I could use for backups.

So I wrote a little program to encapsulate the rsync command along with a bit of code to determine whether a reboot was required and notify me about that. A little later I added code to deal with multiple hosts to backup, and later I added code to handle multiple backup devices so I could have an internal storage drive as well as the external one that I took to my safe deposit box for safekeeping. Then I added code for … you get the picture.

I never found better software to do what I wanted than the “temporary” software I created myself.

Jim Hall created a quick fix that lasted until the system’s end of life:

When I worked in Enterprise IT at a public university, a legislator told our CIO: “We have a bill before us about your course evaluations. If you can make these public in four weeks, we won’t have to pass a law to make you do it.”

Our lead developer said it would take that long to get something into QA.

I had just updated my website to add an open source search engine called perlfect, so users could find the information they needed. I thought, “What if we turned the data into HTML files, I could put perlfect in front of it. Then you can ‘search’ the course evaluations.”

So I volunteered to try it out. It took a day for them to get me the data, a day to automate turning it into HTML, another day to set up and automate the search engine. And then the new “search the course evaluations” website was up.

Of course, my quick fix had lots of “holes.” It searched text on HTML pages, so if you searched for any text that was on all the pages (like “instructor” or “course” or “evaluation”) it returned all the pages. But it was just supposed to be a temporary fix until the developers could write a proper web app.

My temporary fix stayed in production until they replaced the course evaluation back-end.