This is totally me just being naive, I don’t work in the software realm but do have an interest possibly one day, but if we have stuff that’s been able to run (seemingly) successfully for years, or maybe even decade, what maintenance needs to even be done on old programs? Is this simply for people discovering security vulnerabilities and patching them? Is there more to it than that?
In: Technology
People find bugs in software all the time, security exploits included. Just because the software has been running fine for 20 years, doesnt mean there are not issues that need fixed. Maybe there is a memory leak, text input field doesnt accept enough characters, maybe it needs a fix to work on a new machine, etc
(1) All but the simplest software has bugs. AS those bugs are discovered, new versions are released and swapping out the version with a bug for a version without a bug is “maintenance.” Some of these bugs are security vulnerabilities.
(2) Software can also leave files on a computer system that record what the software has done. Those files need to be periodically removed to avoid filing up the computer system and/or store them in an appropriate place.
(3) Over time, databases can end up with a lot of old useless data or get into a state where re-ordering data would make the program run more effectively. Taking care of those problems frequently happens during maintenance.
(4) Some software bugs only show up after the software has been running for a “long enough” time. By restarting the software, you help ensure that those bugs never come up.
When software is written it knows how to talk to all of the devices that are necessary for it to function. However, while the software is in use, new devices are manufactured. The software doesn’t know how to talk to those devices so it needs an update. The update will allow the software to communicate to the new devices and the cycle continues when an even newer device is created.
There’s really five aspects of software “maintenance”.
First is change management – software development isn’t always a “one and done”, usually you find ways to make the software better, and push out an improved version that you either put out for free, or charge money for. Also, when new hardware becomes available, it is prudent to port your software to the new hardware and make updates to take advantage of new hardware features.
Second is bugfixing and vulnerability patching – almost all software has bugs to some extent. Finding and getting rid of them can be a lengthy task. Some of these bugs can also create vulnerabilities that hackers could exploit to compromise a system that’s running the software. Leaving these vulnerabilities unpatched is very negligent. Another aspect of this is updating DRM which protects the software from pirates who are constantly finding ways to get around it.
Third is server maintenance – this is more on the hardware side of things. But some software runs on servers out on the internet. Those aervers are physical machines that need to be maintained as they grow old and wear out. Replacement servers will also have newer hardware, and likely a newer operating system, so it may be nescessary to update the software to accomidate the newer hardware or OS.
Fourth is customer support – usually you see this with enterprise grade software. But this is basically “tech support” for a given program. In a buisness environment, you can’t really sell CEOs on software that doesn’t come with a good support package. Which is a fancy way to say they need someone they can call to resolve any issues they might have with the software that might be impacting their buisness.
Fifth is distribution – In order for people to actually use the software, they need the ability to acquire and run it. Part of maintenance is making the software available for people to download or acquire in disk form. Otherwise it can be lost to time as people start to lose access to it. This also means making sure it can run on newer hardware that people are likely to have, as older machines become harder to find.
When we talk about maintaining hardware, it’s normally because the hardware gets old. When we talk about maintaining software, it’s because *other* software and hardware gets new.
Aside from bugs, improvements, security issues, etc., keep in mind that software runs on a system (the computer architecture that runs it, which usually means an operating system these days, but there are many possible “levels” of system being engaged with modern programs). If the system itself changes in some way, then the old way the software ran may not run correctly anymore. Any actively-used system is likely to have changes made it to for a variety of reasons.
A very dumb example of this: I wrote code in the mid-1990s in QBASIC that worked in part by using some clever memory hacks with the visual system that DOS used. It allowed for much smoother animation than was normally possible with QBASIC by doing some “under the hood” sorts of things. I still have that code today, and it can run in a DOS emulator, but it looks like crap, because the DOS emulator does not use visual memory the same way as an actual DOS PC did back in the day. So instead of smooth animation, it looks like the computer is having a seizure. The code is fundamentally fine for the system it was _originally_ written on, but that system no longer exists and has been replaced with a system that is _mostly_ the same, but not the same in the way that the program requires. This example is a little extreme because of the distance in time between the old system and newer ones (almost 30 years), but the same thing can happen with all sorts of “little” upgrades that happen to operating systems, browsers, etc., which could inadvertently and often unexpectedly create problems for programs down the line.
A more modern example of this: I wrote some web code a few months ago that used an external library that was linked to on the web (and I didn’t have control over the link). Suddenly my code stopped working! It turned out that the library got updated and removed one of the features that my code relied on. So I had to find an older version of the library and link to it, instead, if I wanted my code to still work. (And a long-term issue will be figuring out a way to still use my code with whatever current version of the library exists, because keeping my code locked to an old library is going to probably create more issues down the line.)
Just because the SW doesn’t change, doesn’t mean the environment surrounding the app freezes as well. Changes introduce new friction, which needs to be addressed.
There is ‘theory’ and there is ‘practicality’. In theory, you can write software once and assuming it works, you never ever need to change it.
in practice, people need to make changes to the software all the times. Security vulnerabilities. Bug fixes. New business functionality. Platform updates (Android makes an update, so you have to make an update on your application)…
The other aspect is there is a cost to ‘train’ someone on the software. So it is very very very challenging to not maintain the software and then when a change needs to be done, just bring in some contractors and have them make the change. They don’t know anything about it and so it’s going to be very bug-prone and time consuming for them to actually make those changes.
It ‘generally’ makes more sense for any software in use to have some people ‘maintain’ it.
A specific example comes to mind for this. We had software that was run on a local network through the IE browser (software was written 20 or so years ago). There was an update that restricted how much information can be passed through popup windows. The menus on the website had a popup filter, and in that filter were sections to look up certain factors (example, a popup to pick specific dates on a calendar, or a search function to find multiple companies). We had to rewrite the popup-in-a-popup that was originally written because of this IE update a decade or two after it was first constructed.
You would be surprised. You implement a counter and figure “oh ill make it 6 digits long”. Then the software runs 10 years. And the counter hits 1000000. The software either crashes, the counter goes negative, or rolls back to 1 so now you have repeats in your system. So someone has to go maintain the software and increase the counter to 8 digits.
Meanwhile, by the time you notice, the system has rolled back to 1 and has reached 102. Now you have 102 duplicates in your database. So you have to retrieve those more recent 102 records and add 1000000 to them so they are unique again.
You wouldnt believe how often these small oversights happen!
Latest Answers