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
1) someone finds a security vulnerability. That needs to be fixed.
2) An update to an operating system, change in the way certain drivers work, or something else breaks the software. That needs to be fixed
3) Something you didn’t think of or account for breaks something a requires a change. Early programs assumed the processor on a computer would be consistent and when run on a faster processor, they went too fast and possibly made some things not wait long enough before going to the next step. Y2K was a problem because people didn’t think their program would be used 10 years later without an update so to save RAM they saved the year as 89 instead of 1989… that needed to be fixed.
4) Compatibility with new devices and protocols. You can write a program to read RAW files off of cameras, except RAW is not a format and every single camera model has the data formatted a little differently. Not every manufacturer, every camera model… so anytime a company comes out with a new camera, a program that reads RAW files has to be updated with the ability to read the new camera… that needs to be fixed.
It’s called maintenance but the correct word should be improvement.
The software will for ever run **exactly** as it was when you purchased it. That’s the problem.
Why is it a problem?
* No software is perfect, so you’ll stick with whatever imperfections exist for ever.
* What features users desire evolve in time, and if you don’t update, you won’t get them.
Very short answer.
If nothing outside of the software ever changed, and things continue in the same conditions as it was tested, the software doesn’t need to change.
Things change outside of the software so the software has to change or it will fail at some point when the external changes impact it.
A lot of software you use doesn’t exist in isolation. It connects to various other services on the Internet. If those services change their APIs in breaking ways, your software needs to be updated. They might do this for security reasons or others. Like for a trivial example, maybe you have to change a “share on Twitter” button to a “share on X” button.
You also might run into bugs that only get exposed when your app runs on a new operating system or hardware. Sometimes the result of a breaking change made by the os vendor / hardware manufacturer, but often the result of an incorrect assumption that is technically a bug, but never got the chance to get noticed.
For example, there used to be pretty much two standard resolutions for computer monitors: 640×480 or 800×600. After several years, 1024×768 monitors started coming out and a good number of windows applications broke because of buggy code that said “if the use’s resolution is not 800×600, pop up an error message telling them they need a higher resolution monitor to use this software”. Well, that was the result of bad programming, but it was also pervasive and made a good chunk of software unusable without upgrading (or deliberately dropping your monitor’s resolution).
Think of it like a garden sure it might be ‘perfect’ when you set it up. But
1) Maybe you want new flowers (new features)
2) Weeds growing (bugs)
3) External factors like say a neighbor building a shed near your garden causing shade problems (new operating system upgrade changes something that you have to address)
4) Invasive species found (critical vulnerabilities)
sofware doesn’t exist on its own. Its used by others and sits atop other things. All of those factors are in constant flux and change
And then you have the reverse.
Old PC’s running on Windows XP because the program running the connected machine has not been updated in 10-20 years, and the original company has been out of bussiness quite a while.
There’s two types of software projects: abandoned and ongoing. You can almost always think of another feature to add to improve it, and with a fast changing tech landscape something might be possible today that wasn’t possible 4 years ago when you started.
Let’s talk about software that doesn’t need to be or can’t be “maintained”. Think of a NES console with a game cartridge. That NES console and game cartridge still work even though they were never “maintained”. It’s because the console never changed, and the game cartridge never changed.
The NES console/game is kind of like a time capsule, the system is never changing. No updates, no game expansions, nothing.
With modern software the device and things running on that device are changing regularly. Two systems might need to talk to each other over the internet, or some software depends on a specific aspect of the operating system. There are 1000’s of these communicating systems and dependencies, and in modern times each one of these systems can be updated. So unlike the NES console/game example, this collective group of systems is constantly changing.
Now if one of those things makes a breaking change, you have to “maintain” it to continue for it to work like before.
Car needs maintenance to replaced their parts
Software too need maintenance to replaced their parts – their parts can go out of date, their parts can later be found problematic and need to be replaced.
++++++++
Sometimes you want to add new thing to your car – dashcam, new 360 radio and etc.
The same applies to software engineering – these people that maintained the software ensure this requirement is achieved
I used to work on a Point of Sale system for a large retailer. We had to change the software for several reasons:
* Emerging security threats (patches would occasionally break things, major exploits require changes to several external libraries that we might be referencing).
* Upgrades of our vendor’s software that broke our code or offered features we wanted to use
* Integrating with systems from partners or acquired companies
* Supporting new business initiatives (new types of coupons or promotions, rewards points, etc.)
* Performance improvements (asynchronous design to take advantage of multiple processor cores, etc.).
* Make changes necessary to safely move away from software that was no longer supported (Win XP, old versions of .NET, etc.)
* Employee retention. Nobody wants to work with libraries/languages/patterns/frameworks that are so out of date that your skills become less valuable. This was never the primary impetus for change, but we definitely took it into account.
Latest Answers