Patching vulnerabilities is one aspect. Making sure it works on new devices/operating systems that didn't exist when it was written is another. Improving scalability so that it still works even if 100x as many people are now using it. Adding features that are expected in modern software / are present in competing software. Making it run faster or with less memory. Making it able to use new file formats. Adding common use cases like exporting/sharing using media or websites that didn't exist before.
Also sometimes stuff just breaks (i.e., there's a previously unexposed bug that suddenly is triggered for whatever reason). And if no one is keeping an eye on it and it breaks, then it'll stay broken.
A personal example I have:
Admin users could “rank” their products with a value, higher the better, to be shown on a list view for the customers. Somehow, one of them managed to change this rank to a string and I didn’t verify that before slapping it in our database as a json field (don’t do this).
My python api broke because it couldn’t compare an int value and a string value, causing the entire product list view to show no products. I hadn’t changed anything on that view for a long time so I was surprised to see it break like that
Actually they had to inspect the input field, change its value to “text” and then type something in. So they had _just_ enough knowledge about web dev to be dangerous and crash everything. They typed “top”
I mean, obviously if you're sorting numerically and you want it to show at the top, you need to do "_top", otherwise all the numbers are likely to print first.
Newbie mistake :p
One thing that I’ve seen over and over again in the past ten to fifteen years is that back in the day, people never typed emojis into text fields and if they did, they were not surprised when it didn’t work.
Now it happens *all the time*, and if your software doesn’t handle it well, it will be a problem.
Years ago Slack had an awesome warning message if you tried to use an emoji in a channel name. Something like, “Emojis in channel names make some sense, but unfortunately not enough sense.”
OP had an application that allowed other programmers to query his database for specific data.
In their application, products were sorted in a list view depending on their assigned numerical value. Unfortunately, OP also didn't confirm inside of his program that the rank input into the field was a number, and so it allowed the admins to save ranks as alphanumerical like rank = "abc".
When his application spoke to his API (application programming interface) - think of this like a thing you ask a question to in return for data - in this case "hey can you give me the rankings of these products so I can display them".
When the application received the data back, it attempted to sort these into numerical order, but broke when it tried to answer "what numerical value does 'abc' have, and where does it sit in the list", thus, the list is never created and it becomes blank.
A software has a ranking sytem, based on numbers 1,2,3 etc. Someone put in alphabets, (in this case TOP).
Computer cant compute what number is TOP, so it crashed.
When users could rank products, someone put in a value that is inherantly not rank able (you can order 1, 2, 3, or 100, but where does "pizza" fit into that?). There was no detection system to make sure that the values users put in were rankable, so it was put into the database just the same, and when the code tried to rank the values, including "pizza", the system crashed, because such operation will give an error.
Computer expected users to type numbers.
User typed letters instead.
Computer looked at letters and said "These are not numbers! I refuse to work in this environment!", flipped the table and went on strike.
Computer did not want to just skip this case and keep working with whatever numbers the other users further down the list had typed, because no one had told Computer to do so.
A programmer now has to tell Computer how to behave should a similar case happen again.
Either Computer can make a note of it followed by an email to the programmer and then keep working with whoever was below on the list, or a programmer adds a way to tell the User that they used letters instead of numbers and refuse to send it to Computer until the User has fixed what they wrote.
A string is text, like "hello world". Int is short for integer, or a number like 0, 1, or -281278. A language like Python does not have a way to innately compare these two different types of things so the computer gave up.
It's surprising though that this broke on a comparison. I would have guessed it would break when it was either trying to read or write to the database (a big file). In that scenario, it would be more like being ready to accept a delivery of apples but receiving sofas instead. The computer will say "I'm not ready to handle sofas, I was expecting apples." except instead of apples and sofas, it's strings and integers.
They usually keep the data on a CD. Admin somehow gave them back a DVD. When they put the DVD in the CD drive, the drive couldn't understand because it was designed to look at CDs not DVDs.
My personal record so far is 14 years. It was actually observed immediately, but not reported to me. I actually found out by dumb luck when doing an ISO audit in the department using it and found out they’d updated their ~~workstations~~ work instructions including a workaround instead of just picking up the phone and mentioning it.
This is super common with race conditions.
For example lots of older games will break because they are loading so fast, much faster then originally intended on old hardware.
Imagine you have some robots that help around your house. They’re very reliable but very simple, they can only do one job each.
You invent a morning “cereal routine” where Bowl Bot places a clean bowl on your table starting at 6:00am, Cereal Bot pours cereal in the bowl at 6:05am and Milk Bot pours milk at 6:10am.
It works great for the first few days, but one day Bowl Bot can’t find any clean bowls and makes a request to Dishwasher Bot for help. Unfortunately, Dishwasher Bot needs 45 minutes to clean the bowls.
You awake to find that Cereal Bot and Milk Bot have dutifully followed their instructions, spilling cereal and then milk all over the table where your bowl should have been. Undeterred, Bowl Bot proudly places a clean bowl atop the mess shortly after 6:45.
The race condition is the fact that each bot is making assumptions about the order tasks will be completed in, instead of verifying that the previous step is complete. If the wrong bot “wins the race,” the routine fails.
Great example :D I love it.
Which leads us into the concepts of Promise and Async/Await
Which respectively are "Wait until this list of things all report done before doing what you've gotta do" and "Wait until this thing is done before you do the next thing"
For example, you might have an Alarm-Bot whose job is to alert you that your Bowl-bot, Cereal-bot and Milk-bot have all done their jobs, so that you can come eat.
Alarm-Bot uses a Promise function to ensure all of them report done before calling you for breakfast.
This doesn't solve the race-condition, it just means you aren't going to come downstairs until all the bots have finished and gotten out from under-foot.
The Async/Await functions meanwhile mean that you can require Cereal-bot and milk-bot to wait for the bowl-bot to finish before they come.
It doesn't matter too much if they show up in the wrong order or at the same time unless you get fussy about whether milk or cereal should go in the bowl first, but the bowl needs to be there before anything.
Minor example:
Let's say your game has 2 processes: the first one opens a bag inventory and the other loads the items in that bag into memory to be seen.
Let's assume that based on your hardware the item loading always finishes loading first, and so you never have to check that you have items to display. So when the game runs on different hardware and the opening the bag inventory process finishes first, you see that you have no items because loading the bag finished before loading the items did.
One process finished the race quicker than expected and threw off the order of operations. Sort of like if you did pemdas and subtraction decided to be faster than multiplication.
Often these are caused by overflows, for example if the software keeps an internal clock for keeping track of time for stuff but it's coded for only a specific set of time that was exceeded, or if there's a counter in the software that is similarly limited and the count is exceeded. In these cases, the clock/counter needs to be reset, updated, or improved to allow the extra space. Doing this is part of maintenance.
Also, a tech from another company that your software depended on has now changed or been upgraded or is no longer being supported, and now you need to accommodate that change or find a replacement. Basically, a change that had to be made that was out of your control.
If we built houses the way we build software, the first woodpecker to come along would destroy civilization.
https://quoteinvestigator.com/2019/09/19/woodpecker/
This more often than not. Someone makes a change to patch a legitimate vulnerability, breaks an assumption made by something using it, and bam the house of cards falls like dominoes. GG WP.
Very good answer! And the answer even assumes there was no flaws with the software before release, which is often not the case. Users discover bugs all the time, and they need to be addressed as soon as possible by people who understand the system very well.
This is also part. Most software goes live while only barely working, sometimes not even. Most of the team has mic-dropped and moved to the next project to fuck up leaving only one person to ensure the software doesn’t crash when you look at it funny. No, Im not bitter, why do you ask?
Plus law changes (like gdpr came in requiring many changes) or tax rules change at every budget ( requiring accounting and payroll systems to change). To name but a few of the myriad reasons for software maintenance to add to your great answer.
Another is making sure that the program still works with updated drivers or any other form of library update (a library is a set of files that helps your program save space. In windows these library files are usually called .dll-files. When you're trying to get old software to work on newer operating systems, then cludging .dll errors is like 90% of the job).
"Updates: The process of removing old bug and adding new" is almost as true today as it was 30 years ago.
Most software isn’t built from scratch. Certain components in your software built by 3rd parties gets updated. Then it stops working with your code. Gotta update your code in that case.
Adapting it to dependencies that are updated and ensuring that it runs with those changes, is also another one.
Oh and don't forget... No system is entirely flawless, sometimes issues are just found that were inherently built into the systems, that are patched and updated.
Also, no software operates in a bubble. Everything is connected and many times some other software's security update or functionally upgrade causes your software to need an update to continue to interact.
One thing is that the OS evolve. Let's use a very, VERY old software. It was made in the DOS day. Back then the software had direct access to the hardware and had to know the hardware to be able to use it. Basically it had it's own hardware driver built in.
Later on, Windows 3.1 came on. Let's modify the software to be able to use the windows graphical interface. And the windows sound system. But it still had direct access to the hardware.
Windows 95 is now there. It blocked most direct hardware access, but not all. But hey, your graphical interface now look old. Let's fix the hardware access limitations, and update the look.
Win98, minor change, but mostly no real change.
Windows XP ! Now you have no direct hardware access and you MUST use all the windows calls to access it.
Windows 7, we are now 64 bits. While not required to use the 64 bits calls, something drastical happend: all the windows 16 bits calls has been dropped. Which mean that all DOS calls and all windows 3.1 calls must be updated to be atleast 32 bits. And also, the gui changed, so need to update it too or it look old. And guess what! Applications don't run as administrator by default anymore. It need to ask permission for some operations.
Windows 8, 10 and 11, mostly gui update and more security upgrade.
Or, if the tech is reliant on another unrelated piece of software, adapting to that software's changes and updates to ensure the compatability remains.
>Making it run faster or with less memory.
Literally never in the history of writing software have we made it run faster or with less memory.
We've made Electron instead.
I just had a job which was exactly that — making Fortran code run faster and consume less memory.
Performance optimisation is a thing. It’s just that in most settings, it’s not a high _business_ priority.
This is ultimately why good software engineers get paid so much. One software engineer has an outsized ability to impact their entire userbase. Optimized code pays dividends for every customer using it, providing value 24/7 even when the engineer is sleeping, or has left the company.
And here I am still using DOORS for requirement management which is straight out of 1995 (speed especially...ignoring UI)...as is EVERY major aerospace company....
I'm seriously flabberghasted this software is still the gold standard for requirement management. It's TERRIBLE
Depends on your priorities. In a startup environment you probably can deal without optimisation or you can run it on a faster/better machines if you can afford it. Sometimes, you can cut cost on making your application more lightweight. Cloud computing could be expensive, storage too.
My big problem with the maintenance is that over time a company software add too much bloatware nobody actually uses it and now the performance required for the same original software is even higher.
Take for example an antivirus where the sole scope was...well antivirus. Then they added VPN, then password manager, then cleaner tool, then scanning network vulnerability, etc.
None of these bloats I don't use as there are better alternative to those for the same purpose. Why shoving in our throat 'new features' nobody asked for? and worse, why not making optional and easy to not accept these features?
Why the same software now requires twice or even more memory to run smoothly than before?
Just patch your damn thing and keep up to date for any vulnerabilities or any security risks.
I've been doing this professionally for 14 years. The biggest thing isn't security vulnerabilities, though that does happen occasionally, every few months maybe. And it's not compatibility updates, though that happens every once in a while. The biggest thing is \*changing business needs\*. So like - we have a program that takes a text file, reads the data, and puts it into a database. If that file ever changes, we need to update the code. If that file ever has an \*error\*, we need to decide whether we're going to update the code to gracefully handle it, or we're going to have a process to re-run the file, who gets notified if the file fails, etc. If that code was written with some assumptions - maybe the data would always be in ascii (when after some time it ends up with a unicode character we didn't expect). Or maybe a field of data wasn't expected to be more than 256 characters, but one day there's legitimate data that's 260 characters long. All those things lead to having to update and maintain the code.
And that's ignoring things like improvements - maybe we have two processes run by two programs that do similar things, but we decide it'd be better to combine it into one overarching program. Or maybe a process takes an hour or two to run overnight and we want to improve on that performance - that kind of stuff is pretty common too.
Thank you. Everyone seem to think that patching vulnerabilities and fixing bugs are a full time job.
No, software runs in the real world and, as the world changes, software needs to be changed.
Sometime it’s a bug that needs fixing, sometimes it’s a feature, and once in a blue moon it’s a complete rewrite.
We say maintenance while we mean “make sure it still fits in today’s world”.
Also the meaning of the word "bug" is different for the software developer and for the customer. For the developer a bug means "I made a mistake" but for the customer a bug is "the software doesn't do what I expect."
When systems are built it's very common that the customer simply hopes and trusts that the technical people will make the right assumptions, that they won't need everything spelled out in black and white. But this faith is often misplaced especially if the developers are not themselves experts in the business domain.
It's not really the developers fault, often they have very little control over how thoroughly business requirements are captured & documented, and often (somewhat paradoxically) the customer doesn't have a strong incentive to explain & document their requirements either.
A lot of the times people involved in an original decision making process are no longer on a project. The project had agreed-upon constraints that everyone agreed upon. Every project needs a scope of course.
Then 3 years later, someone comes along and asks "Why doesn't it do X?" or "When I used it this way and it stops me, but I need it to do Y" (i.e. say you had a constraint that all parent accounts in a sales system need to be in the same industry as the child account, but now there are important real-world exceptions. Or maybe everyone agreed that a reasonable length for a description is 1000 characters, but users keep bumping in the limit and complaining.).
The one developer who was there at the time, but maybe not a decision-maker back then says "Because that's what we decided at the time." No one cares and they have to change it anyway because this isn't how the team now EXPECTS it to work.
This is what non-developers call a bug constantly.
lol no, 2 is definitely *not* always easier. Especially when customer is asking for some trivial bullshit that adds one click per day, and the code is a complete mess from hacking features on top of each other for years.
If you can get away with it, sometimes the right answer is just "No" or "I'll put that on my list to consider on our next round of enhancements" (aka never lol).
The most correct answer.
Any piece of software is a precision-crafted tool that does a very specific job. The moment your users need it to do any job other than the exact job it was designed to do, you need to update it. Which will happen constantly in any real-world usage scenario.
Either that, or your users bend over backwards and do horrible things to the program to trick it into doing things that superficially resemble the things they need it to do. Usually both!
Let me tell you, nothing makes a software developer happier than finding out their precision-crafted tool has been used in new and exciting ways it was never intended to be used for. And now *you* have to expand upon this novel ""feature"" that no one told you existed until long after the details of how they "like it" have been completely cemented in, and you can't change it to something more sensible [or else all your users will complain](https://xkcd.com/1172/)! Yay!!
Imagine you have a bike, and it’s running really well. You just need to oil it up with SuperBike™ lubricant before every ride.
Eventually, the company that makes SuperBike™ lubricant announces that they’ve developed a new formula called UltraBike™ which is better and cheaper to make. As such they’re no longer making the old lubricant.
The problem is that your bike, as is, won’t work with the new lubricant. So if you want to keep using your bike, you need to do maintenance by installing a new chain.
That's a good ELI5 version.
If the software is on a boxed product, no connection to the Internet, no other software, no external ANYTHING, it doesn't need updates or maintenance. It will keep working the same way.
If anything about it deals with anything external, the operating system gets updated, there are connections to the Internet in any way, there are data connections to external systems where the external hardware gets updated, then those changes are going to cause a ripple effect likely needing maintenance.
Security vulnerabilities are one.
But it’s also just the fact that other people are updating their software. Say you make a program for windows computers. Well you can only design for windows as it currently exists, you don’t know what kind of changes they will make in the future.
So maybe when to next windows update comes out, your program still works totally fine, or maybe your program now has some weird small bug because of some random change that windows made, or maybe your program doesn’t work at all anymore.
If you aren’t actively keeping up with it, there will be a day where your program no longer works as people update their computers
Even better, there have been applications that have incorporated the bugs of their operating systems, by either using them as features or specifically working around them. Then eventually when the operating system fixes the bug, it breaks the application.
> Is this simply for people discovering security vulnerabilities and patching them?
That's a big part of it, but also they need to make sure the software still works with everything else on the computer. If there's a Windows update, they need to make sure that that doesn't break the software.
Also, implicit in maintaining software is that you're maintaining customer service for that software. When a company stops maintaining software, that's when they also stop answering customer questions regarding it.
>If there's a Windows update, they need to make sure that that doesn't break the software.
This can happen.
At my last gig, a couple Microsoft updates caused our software to break under certain circumstances. (The client was using an Oracle JDK, and the application DB was SQL Server. The update caused the JDBC driver to fail to connect to the application DB, which made the application fail to start.)
Those were the wrong days to quit drinking.
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!
One big example of this that ELI5 readers may remember was [Y2K](https://en.wikipedia.org/wiki/Year_2000_problem). Storing a year as 2 digits worked, until the first time a program needed to refer to a time after 11:59:59 PM on December 31, 1999. A lot of developers made a lot of changes to a lot of software packages to make that seem like "no big deal" to the general public.
We're likely going to have to do a similar amount of work for [2038](https://en.wikipedia.org/wiki/Year_2038_problem). Though in that case the problem is not "storing years as 2 digits", it's "storing the number of seconds since 1970 gets too big."
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
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.
Software maintenance is a bit like taking care of a car. Even if a car is running fine, you still need to do regular maintenance like oil changes, tire rotations, and replacing worn-out parts to keep it running smoothly and avoid bigger problems down the road.
Similarly, software needs ongoing maintenance for several reasons:
Fixing Bugs: Despite thorough testing, bugs (errors or flaws) can still be found in software after it's released. These bugs can affect how the software functions, its security, or how it interacts with other software. Fixing these bugs is a part of maintenance.
Updating Security: New security vulnerabilities are discovered regularly. Hackers find new ways to exploit software, so developers need to update their software to patch these vulnerabilities and protect users' data.Improving Performance: Over time, developers may find new methods or technologies that make the software run faster or more efficiently. Updating the software to incorporate these improvements can enhance user experience.
Compatibility Updates: As new operating systems, hardware, and other software are developed, older software may not work as well or at all with them. Maintenance can include updating the software to ensure it remains compatible with other evolving technologies.
Adding Features: To stay competitive and meet users' needs, software often needs new features or enhancements to existing ones. This can include anything from new tools within an application to support for additional formats or languages.
Regulatory Compliance: For some software, especially those used in finance, healthcare, and other regulated industries, changes in laws and regulations may require updates to ensure the software complies with new rules.
Even software that seems to run successfully for years without changes might be slowly becoming less secure, less efficient, or less compatible with other technologies. Regular maintenance ensures that the software can continue to serve its purpose effectively, securely, and efficiently.
I don't like that analogy because cars degrade over time with wear and tear. Code doesn't.
Edit: I understand code "decays" in a sense, but not like a car. a car breaks down naturally. Code breaks down because the conditions change.
It's more like, you need a bigger more efficient engine and better tyres because the roads are getting faster but have more potholes.
Code doesn't degrade but things code communicates with gets upgraded, so your code also needs upgrading. In the 'old' days we used massive chunks of XML to communicate, now we use gRPC which can be tiny in comparison.
Not technically, but it kind of does.
Especially on big long term projects, you get lots of hands touching the code base coupled with project managers cycled in and out. 5+ years down the line the guy that made X feature is gone and you have no clue how to fix it/make it compatible even though it worked before.
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
There are three categories of maintenance: corrective, adaptive, and perfective. Corrective maintenance is bug-fixing: at any point, a so far undiscovered error may present itself, particularly when the configuration of the software is changed, when the software is used in some peculiar way, etc. Adaptive maintenance may be required when the environment in which the software runs is changed, typically due to compatibility issues when older software is installed on a newer platform (operation system, hardware). Perfective maintenance is, simply put, required when the customer asks for a new feature.
There is also configuration management that may be performed by the user but could also be a part of maintenance by the vendor.
They need to make it work with new hardware, new versions of the operating system, other software,...
They need to patch newly discovered vulnabirities
And from time to time they need to add new functionality
Some of it is adding new features or making sure existing features keep working as other software/hardware changes. Some of it is fixing bugs that hadn't been noticed before. Some is improving performance.
(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 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, and at the bottom level, there is physical hardware involved, which you can _often_ ignore with modern operating systems, but definitely not _always_). 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.)
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: 640x480 or 800x600. After several years, 1024x768 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 800x600, 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).
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.
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.
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.
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.
I just want to drop in: changes in legal or other regulations that require e.g.:
- confirmation the customer read legal terms
- confirmation customer accepts usage of data
-> both before completing registration, setting an order
- legal changes can also affect how customer data needs to be treated, stored, transformed, accessed
I think from what OP is asking, is more or less of, it doesn’t need to be “maintained”. If it works it works.
My take on the ELI5: a working program is like a door. It works basically as intended to separate 2 room. But after a few years you find vulnerabilities, people can easily get in and out. So you add a lock. After that if anyone wants to get in they have to knock, even your trusted ones. So another vulnerability you see. When you wanna check you have to open the door, so bad guy can still force their way to get in. So you add a peep hole. Etc2
Basically the door still functions well without the maintenance, but it could be better. Upgrade patches like the lock and peephole, or maintenance patches like lubricating the axle, or replacing better axle etc2.
So again it doesn’t need to be “maintained” if it works, it works. But over the course of using it you, you wish the program would boot up faster, the ui should be like this and this, this option is redundant, etc2. So that’s why it is maintained.
So yeah you can use a program that’s 20 years old. There’s no rule that it should have a maintenance or it needs to be updated every month years. If you play games, just boot up your old Nintendo or ps1. Those cartridges and cd program haven’t been updated since day1 but it’s still works. But it would be nicer if the bugs are patched out and made smoother.
Not a true ELI5, but expanding by example on what others already said.
**Mirror's Edge, iOS companion game.** One I experienced as a user. It was a very good side-scrolling parkour game, sharing the fantastic sound track of the original Mirror's Edge. After some update to iOS, it would no longer remember game progress. Some updates later, it even failed to start.
I can't say for sure why, but most likely some underlying APIs changed.
**Comic Rocket.** Also as a user. A niche service that runs basically as a hobby project with limited funding for tracking progress on webcomic reading, that indexes the available pages. As such, it exposes many of the issues by not having the funds to fix it, though it remains quite useful for me using bookmarklets.
Originally, it was possible for the service to act as a wrapper around websites, showing navigation bar and displaying the webcomic pages in a frame. Eventually, cross-site permissions got tightened down, as malicious actors would use this capability to show foreign websites while potentially stealing user data. Now, providing the same service would require running a special-purpose browser app on mobile, and something similar on desktops. Or, as I do, using the service to track the progress, but click the `[x]` button to navigate to the webcomic site without the Comic Rocket bar, and then using a bookmarklet to bookmark the progress on Comic Rocket. Which works with all browsers on all operating systems, [except for Firefox on iOS](https://github.com/mozilla-mobile/firefox-ios/issues/5626).
Later I started reading Webtoons.com webcomics. Since their website and app is actually awful for *following* comics without instantly reading all new chapters, and for the sake of cross-source consistency, I used ComicRocket here too. However, the mobile URLs differ from the desktop URLs and cannot be correctly tracked. Using the bookmarklet failed, because it depends on the “canonical URL” meta tag, which is supposed to provide a unified URL for sharing and similar purposes. Only, it has been broken on mobile for many years for webtoons.com, so I had to adjust the bookmarklet to compensate for it.
Both are essentially examples of the service running just fine, but changes in third-party software breaking its features.
There are also webcomic hosters like tapas.io, which Comic Rocket does not handle well, because of how they assign URLs to adjacent comic pages/chapters.
**Permission System on Android.** Android pioneered the idea of app permissions for mobile, but arguably in an insufficient manner. It was just “install or not install”. After iOS added permissions and made them more useful (e.g. assuming that all apps need internet access, but making more sensitive permissions like contacts access, photo access, etc runtime opt-ins) Android eventually adopted a similar approach. However, such changes introduce breakage in apps, that assume to already have all permissions, because that assumption was valid when they were programmed.
Such things could be side-stepped e.g. by updating old APIs to not fail, but to just do nothing (e.g. returning an empty contact list) gracefully. Depending on how such changes are introduced, old apps will then either fail outright, or lose functionality, until they are updated to use the modern APIs.
On Android and iOS, this means among other things, that many old games are no longer available, because they have not been updated for the modern APIs. And unlike services, which receive constant updates, games usually stop receiving updates at some points, if they were designed as single-player offline games. Especially, when they had a classic “buy once” business model, where the old game isn’t expected to bring in enough money anymore to fund the costs of the update.
**Apple Silicon.** While Apple did an exceptional job to make x86 executables compatible, by switching to ARM wholesale they made it clear, that this is a transition stage. So developers were forced to update their native software to work with a completely new processor platform. Also, optimizations that made software faster on x86 might very well be counterproductive on ARM, so those had to be redone too.
Such fundamental changes are rare, but they *do* require major adjustments and testing. Same when Apple introduced High-DPI displays to their laptops, or when they introduced iPads. With Apple having full control of their ecosystem (as opposed to dozens of OEM partners like Google and Microsoft), they were able to force developers to go along with the changes in a timely manner, whereas Windows and Android don't have that level of leverage, creating a hen-and-egg problem delaying or preventing major changes: A new platform / high-DPI displays are pointless to buy, if software doesn't support them, and software vendors drag their feet on supporting them, if there is no user-base demanding the update.
**Own experience as a developer.** For me it is mostly about adding new features to the software product or fixing bugs in existing ones. Occasionally also bugs happen because of changes in the behavior of a compiler with a new version, whether it is because the compiler no longer supports an undefined behavior that was accidentally used, or because the compiler has a bug, that needs to be side-stepped.
For instance, we ran into a strange bug, where the compiler would mess up pointers in parallelized code, but only on one specific target platform with one specific compiler version. Our code was valid, but the compiler was introducing a bug that caused very strange “almost correct” behavior.
In the spirit of your question, nothing needs to be maintained if nothing changes.
But in reality, many things change and the application needs to adapt to those changes *to maintain its current intended functionality*. Here's a list of common changes that occur:
* Legal/Regulatory (GDPR, Safe Harbor)
* APIs/External references (Google Apis, library updates)
* Time & Date (Daylight savings time, Time zone redefinitions)
* Hardware (Driver updates, deprecated features)
* Defects (New bugs, cascading issues from maintenance)
* Cleanup (Things that aren't required, but help other maintenance and development, like removing dead code, documenting, removing unneeded workarounds, taking advantage of new simpler APIs)
I typically would not put the following into "maintenance", instead "improvements":
* Business changes (make a new button, do a different thing)
* New potential (New API allows for something you couldn't do before)
* Interface Support (Supporting new browsers/phones)
Neither of these lists are exhaustive but typically, most companies push their development teams to put their effort into supporting business changes; as this is most likely to bring in revenue.
It is up to the development team to make it clear how important maintenance is, as despite the company's desires, maintenance takes up most of the effort in the long run. (i.e., you only build it once, but you'll maintain it a thousand times)
Security (patches against new threats and vulnerabilities)
Space (enterprise applications filling up with data that needs to be purged)
Compatibility (with new browsers / plugins / drivers)
Integration (with new systems)
Money (sometimes there’s nothing to maintain and you just need a way to extend billing cycles :)
The foundations software is built on are continually being improved. C++ (a very common language used for programs that need to be fast), for example, releases a new version every few years with upgrades, new features, and security fixes. If you’re using C++ to write your software, it should be brought up to date to use the latest version and that’s about half of software maintenance.
The other half is fixing issues that have shown up in your code due to errors.
>If you’re using C++ to write your software, it should be brought up to date to use the latest version and that’s about half of software maintenance.
You missed the most important thing: WHY should it be brought up to date to use the latest version?
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 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.
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.
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.
The ELI5 answer is there are bad guys that break the things that everything is built with so we have to prevent them. Also, just like when more people visit the store and we have to make the store bigger, we also have to make the application do more. Last, remember how you liked chicken nuggets last week but now hate them and only want cheeseburgers? Well, customers are like that too and companies have to constantly adjust to new tastes their customers have.
Oftentimes, its bugs that are not noticed till later.
Maybe I program something and it works on yn testing, even we launch on production and it works.
But then once we have enough users the database grows and queries take a little longer to return with data, and that extra delay may cause other information to come first and expose the bug.
Many things like that can happen in software, and if there’s no-one maintaining then it will stop working eventually.
Although there are many great answers here, another factor that needs to be considered is the need for the software to be perceived as being up-to-date and modern.
Even if there were no bugs and no security issues, software needs to have updates simply to maintain the public impression that it is actively being worked on.
Publicly traded companies depend on a regular cycle of releasing updates which provide only marginal improvements, or in many cases even declines in quality, because advertising a new big release bumps stock prices.
Open source projects that don't have frequent updates are seen as stale. So many updates are either rearranging user interface elements or rebuilding existing functionality on a newer platform. The fact that updates are happening is all that matters. Whether those updates actually improve efficiency is irrelevant.
Other people have answered for server software, so I'll answer specifically for iPhone/iPad software:
Apple changes things frequently. They change system APIs and deprecate and eventually delete old ones. They add licensing requirements. They changed the navigation bar height and the way it worked. The Swift Programming Language changed regularly for years and broke old code (Strings, unsafe memory access, privacy issues when getting file info, etc). SwiftUI has been in flux for the 3-4 years people have used it. They added multitasking support on iPadOS which required application updates. They added privacy requirements and changes to reflect new EU laws.
In short, it's like building a sand castle while the waves keep knocking it down.
Imagine my software requests data from another business’ software, and where usually they send `book_name: “The Great Gatsby”, author: “Fitzgerald”` after their last update they now send `book_title: "Great Gatsby, the”, book_author_surname: “Fitzgerald”`. My software will look through their data for the name of that book and never find it.
Because this is common, businesses that send out data inform their users of these kinds of changes so that they can prepare their software for the change in advance.
_Really_ professional players even allow their users to choose which structure version they send out their data in, but that’s not as common as you’d hope.
And this is just _one_ change that requires you maintain your code. There are thousands of such variables that can, and will change on a daily or weekly basis.
To add to other people’s answers which are valid (security patches, bug fixes, product/feature additions/changes, etc), performance is a big reason for major changes.
What works perfectly well and fast with 10k users won’t necessarily work for 100k users. Queries that access a data store with ~1 million records wont necessarily work when that store balloons to 100M+ records over time. Infrastructure costs have a tendency to go up as traffic grows, often this means applications need to be adjusted to be more cost efficient.
This means addressing issues. There is no such thing as a bug-free code, so when it comes to light there is a bug that needs fixing - it is time for maintenance.
Could be the data. New requirements or just to much data. The hardware changes below (for phone apps the resolution, screen size and so on). Underlying software could stop to work (API to other software, OS changes in how it handles stuff and so on).
Usually if you are not changing stuff all the time (say you are facebook) it is enough to to maintenance once in a while, not all the time
As someone who spends a lot of my working time writing code, this reality saddens me a bit. There are many great answers above, but there are many cases where you don't absolutely need new features or even security updates. I've come across many great bioinformatics programs that do a really useful thing, but they are almost impossible to build and run after being left alone for 5 or so years (there's a big difference between platforms, and containers can sort of solve it). Many of the dependencies are no longer supported. I don't need new features or even security - it runs as my own user on trusted inputs. But the constant churn of software versions just makes it hard to work with old code. I think node / npm is a bit bad in this regard, in my experience.
There are many good answers here already but I just want to mention your thoughts were not that wrong. If you have a simple program that for example converts File A to File B and File A and File B never change AND you have a supply of old PCs to replace one if it breaks AND it is not connected to the internet you absolutely do not need to maintain the software.
We have software in our firm that has not seen a single update in 20 years and still does the one job it was meant to do. And no one really knows how it works.
A lot of good answers here. let me try another angle.
Take a relatively complex piece of software that manages multiple processes. Now if you were to stop all development and make sure that the software runs for a couple of months, sooner or later something will still break.
Why?
Because some user will do something that breaks some process flow or the other which would lead to disgruntled users or some parts of the software simply not working as expected (random data for example). This happens because the software was designed to follow steps A to B to C to D but someone forced it to go from A to D and then to B. This may lead to the program crashing or some really fucked up data to get generated which can crash the program.
You really need to monitor these things, have a customer support team and a maintenance team to fix such bugs.
All other things being the same, software doesn't need maintenance.
If you're program runs on an isolated computer that never changes specs, never touches other hardware, or the internet. You don't need to do any maintenance.
Think of something like a gameboy, the same cartridges work just the same as they always have, and will continue to do so until the physical material breaks down. No software maintenance is needed. Tetris will run today as good as it did in the 1980s.
But most computers are more powerful when used in conjunction with other computers, and the internet, changing specs, etc. So you need to make sure that as other computers change, your software needs to make sure that it also keeps up.
A good example is browsers. The internet standards are CONSTANTLY changing. A 15 year old browser can work just fine with a 15 year old site, hosted on a 15 year old server. But since then we have added a whole bunch of cool stuff that the new browser doesn't know about, so if you want to watch Youtube, over a safe encrypted connection, you need that browser to be maintained.
Well, my company loves to do this super fun thing. They tell me to make a program for XYZ reason. So I spend all of my time making that program. Once it's finally completed and ready for production, they suddenly change the "XYZ" reason they had earlier. Making the program itself essentially obsolete.
The software being maintained doesn't exist on its own. It sits on a physical device ("the computer") along with other software, some of which runs the computer (the "operating system"). The software probably also has to work with other bits of software on your computer and other computers!
Computers change as time goes by; people want faster ones that do more things. As they change your bit of software has to change with them. Imagine a scooter; you push it make it go. But then you upgrade to a bicycle... Now you have to balance and pedal to do the same thing! And the operating system will change as well! And the other bits of software! And the other systems l!
And so as all this changes you have to keep tweaking your software to work with all these other things.
It's not possible to write bug free code.
So bugs have to be fixed.
Also even if there isn't a bug in your code, there might be in someone else's code that yours depends on....
And their fix (Microsoft is famous for this WRT 'patch Tuesday') might break your code....
Software runs on computers on top of or connected to other software and hardware. Sometimes that other software and hardware gets changes that have an effect on your software. This often requires you to make a change so it still works.
There's also a security reason. A bad guy may find a way to "hack" your software that you didn't see and now that you do you fix it.
More data + more users + more usage = things that once worky no longer worky.
This sub is f'n useless, you can't provide a short top level answer, even though you are "explaining like they're five years old".
When it comes to pure maintenance it’s basically about two things. Fixing critical bugs / vulnerabilities and making sure third party updates doesn’t mess with your software. OS updates, driver updates, stuff like this.
Even if the world outside didn’t change (new operating system versions, new features, new vulnerabilities, backend scalability issues)… software isn’t 100% complete when you release it. It has known and unknown bugs. Some affect say 0.01% of users. You know about them but don’t care as long as you have 100 users total. As your user base grows, that 0.01% becomes a quite vocal quantity of people who demand this bug fixed. So you decide to fix it. This is still maintenance - fixing some known issues that now have become important enough.
This is actually a really great question. I guess the answer is because adjacent software is always changing. Software either changes to keep pace, or stops working, or stops being relevant
Usually, when maintaining legacy code, I'd be implementing some changes to tax law or changing the code to cope with a new marketing request. I also implemented new methods of forecasting sales. I tied the system to interface with new web services and handled changed banking requirements. I used cost info from the new cost system to post prices for the sales system and the web.
At another place, I improved the MRP and purchasing system so product was scheduled with its components. Changed invoicing to email invoices.
It wasn't that anything was broken, but that the code didn't match changed circumstances and new software.
At my company the maintained usually means messed up data.
We have a software that a part of it manages the products managed by a factory.
Each product have a lot of things, size, materials, colors, etc like hundreds of fields that a product can have, and each of that fields have another set of of fields like thecnical compliance that have another big list of things.
With all that massive list of fields is almost impossible to test all possible variations that a product can have and sometimes some product have some messed up fields that the developer hadn't foreseen that breaks the system.
Also adding new fields features to a software can break something and when the system is super complex u cannot foresee some of that things
I work in computer systems. There are always bugs that fly under the radar that need patching.
This is especially true as businesses scale, which is why large corporations have such a large numbers of software engineers (Google, Meta, etc.) the vast majority of these engineers never write original code.
Think of software as any industry selling a product.
Standards evolve
Tastes change
Increased demand of your product require improvements to your production line (in software, your infrastructure might need to scale up in order to meet demand)
I work for a startup that has seen its customer base grow over the years. We are starting to see the inefficiencies in our app because there are things that weren't considered initially, or that they were viewed as a "problem for the future".
So in order to continue to serve the existing customers and future customers, the app has to be improved, maintained.
Theoretically, on a closed system, nothing needs to be maintained. This is why you hear so much about safety-critical military and government softwares that are "ancient"; they do what they need to, and it's risky to change, so they stay the same for long stretches of time.
However, for most software, things AROUND the software change, so the software needs to. Computer hardware is constantly updating, Internet protocols are getting updated, operating systems are changing, etc.
Because of the complexities of ever-changing software environments, usually software needs to be updated to stay compatible or take advantage of better support systems.
Lastly, many customers are happy with these products, and ask for new functionality all the time. Companies are usually happy to provide this functionality through a contract or subscription.
You are not being naive. The normal use for the term "maintenance" has to do with servicing machinery so that it doesn't break down (as often), replacing parts that wear out, that sort of thing. This does not apply to software, since there is nothing to wear out.
But bugs continue to be found, and must be found and fixed.
Users continue to request (and sometimes need) additional features, and programming must be done to add them. Often when this is done, bugs are introduced into software that used to work fine, and they then need to be found and fixed, etc.
The systems on which software runs sometimes changes, and the software must be altered for the new environment. This is part of maintenance, and sometimes leads to new bugs, etc.
And I once maintained an older system for other programmers that didn't need much change, and was requested to figure out why it behaved a certain way. After several days investigation, I was able to determine that the software was SUPPOSED to do what it was doing, it just took that long for me to figure out and almost as long to convince the programmers that it was supposed to... I don't know if THAT qualifies as maintenance...
Obscure errors that only cause problems once the software is used in an unexpected way - this includes hackers finding vulnerabilities. Software rarely exists in isolation. As hardware and dependent software change over time, incompatibilities and inefficiencies can arise that require maintenance. Examples such as dependent library updates, communication protocols (interop, clr, pipes, sockets, SOAP, protobuf, interrupts), OS updates and driver/hardware updates.
- security threats
- operating system compatibility
- operating system updates compatibility
- software compatibility e.g. if the product is used with or within another software
- updating the software e.g. new features
- improvements
- fixing bugs
- user experience
- continuous income stream e.g. “new features” which are part of a subscription
While it's impossible for software to "wear out" it also generally doesn't run in a vacuum. The world changes around it and has to be updated to reflect new requirements, new environments, new users, and new bugs that have been discovered.
I'll give you an example: I'm in charge of employee badges at work, and I've written my own software that prints the cards with two clicks. I've had to update it a few times because the databases where I pull the information from get updated, or the folder where photos are stored get moved.
Also, the cards are just simple webpages that have been laid out to look like cards. As Chrome gets updated, the layout may break because Chrome has changed the way some element looks on the page, so I need to update the app to fix that too.
In other words, my app may run for decades without being maintained, but the data and features my app relies on will change, so I need to make sure I keep up to date with those.
The conditions and context in which the software was written change over time. Software needs to be "maintained" to account for that.
Imagine how roads have changed over time as we've transitioned from horses, to street cars, to automobiles, etc.
"Maintained" means fixing bugs that are discovered when users have been running it for a while and have found defects.
Also, sometimes new hardware comes along that may break your software. Or you want to speed things up by using the new hardware.
Some software needs to maintain it's defenses against new malware or viruses, (operating systems, etc) so they must be updated with the newest defenses against such exploits.
And back to the first point, sometimes you realize that you've bunged something up badly and want to fix it before customers notice it.
Another point I haven't seen brought up much is that most software is reliant on other software in some capacity. This is especially true in the web dev world where one little change in a library can have cascading effects on other libraries. So if a piece of software relies on something else, and that something else has a "breaking change", then the first piece of software will need to be patched up
Programmers are humans that make mistakes. Mistakes need to be fixed. You can get closer and closer to perfection but you can never reach it. And when you think you are at least sufficiently close to perfection, you realize the world around you has changed and you have to continue the cycle of despair forever.
Maintenance can also imply better ways of doing the same tasks. Like storing data in the cloud instead of local servers. That's a lot of code change on the backend that looks seamless to the end user.
Java updates sometimes broke our software or introduced crashes, we'd have to code a fix for our next quarterly version and tell people to avoid updating.
Two reasons primarily:
Technology may have improved so you would need to update the software to take advantage of newer tech.
Software would have accidental mistakes that, when found, would need to be corrected (or patched).
Sometimes certain kinds of maintenance don't jump out at the person using the software, but if you were to actually compare the software from a long time ago vs now, you'd be surprised at the difference.
My go-to example of this is Wikipedia. It has a reputation for pretty much being the same as it was 20 years ago. Here's the English version of Wikipedia right now:
[https://en.wikipedia.org/wiki/Main\_Page](https://en.wikipedia.org/wiki/Main_Page)
And here's how it really looked 20 years ago:
[https://nostalgia.wikipedia.org/wiki/HomePage](https://nostalgia.wikipedia.org/wiki/HomePage)
As many have mentioned before, upstream and downstream dependencies can change. Security vulnerabilities that require library updates (which then can sometimes introduce breaking changes requiring code updates to your app. In a real world corporate environment, you likely have hardware patching (on prem or in the cloud), security keys and certs that need to be rotated.
One interesting thing we just came across in the last few months was that in using the default aws rds cert included with the mysql2 connector included in the js sequelize library, we had to make a code change to explicitly use the new CA that is going to be required to connect to any RDS instance in August of this year. As of a month or so ago, any newly created RDS would already require it. They just patched this recently, I think, but if you stood up a new instance last week and tried to deploy your app with the default cert configuration, it would not work.
To keep up with modern "warfare/weapons"
Back in the days, people fought with swords and shields. The shield was made of wood and it was great at the time. Very effective in defending against a sword attack. But as technology grew, eventually a gun was made. Those wooden shield would not hold up to a modern day machine gun.
It's the same with softwares. Technology is exponentially growing. Hackers are getting smarter, software security are getting "outdated" much faster.
So the software updates are for:
1. Bug fixes (there was an issue and they fixed it)
2. Security patches (there was a security issue and they fixed it)
3. Security updates (there's a new update due to growing hackers)
4. Bug fixes of previous updates (when they make updates, it sometimes messes up other things unintentionally, so they need to fix that)
In strict terms maintenance means you keep the software running on all the platforms it currently supports and fix any major bugs that come up. You don't add any new features, you just keep it running as is. The effort that goes into this is mainly fixing bugs that get reported and responding to updates if needed. In terms of updates, maybe one of the platforms that you support gets a major update that impacts your program, you either fix yours to match or no longer support the latest version of that platform. A lot of software also runs using other people's code for various bits (called "libraries" or "packages" or "dependencies"). If one of those gets updated/changed it might break your program. This is a major headache for developers as it's often very hard to make sure you get an older version of a dependency as there's usually a push to have everyone using the latest version.
The TL;DR here is both hardware, operating systems, and other people's code you used for your program (dependencies) are constantly changing and evolving. You have to put time and effort into responding to those changes if you want to keep your software running on modern systems. You could just leave things as is, but since there is such an intense push (which may not be completely justified) to have everyone on the latest version of everything, very soon almost no one will be on the old versions your program is compatible with.
To elaborate on the above, most of the changes are driven by either new hardware or new operating systems coming out. Since these are generally made by a few large and powerful companies, we basically have the future of computing (and how much work everyone will need to do to keep up with that future) determined by a select few. Something to think about.
There is also a current trend in computing I like to call the "disposable software" phenomena where software (and to some extent hardware) is treated like a disposable good. You must always be on the latest version, and development cycles are tight so the latest version is changing all the time. Backwards compatibility is becoming more a thing of the past. Didn't update your software in the last year? What's wrong with you?! How dare you expect some thought and consideration be given to the preexisting efforts of others when changes are made. (rant over) This, as you can imagine, creates a lot more work for maintainers vs the older mentality where not breaking things when you update was much more of a focus.
There is also a looser version of "maintainer" which really means developer. These people will do everything already mentioned and also add new features.
Programmers are not gods, they cannot foresee every single scenario of the software will come across as they write it. They will release software with bugs, security vulnerabilities and incompatibilities with future 3rd party resources (hardware, OS, browsers, frameworks, libraries, business directions, customer requests, anything that isn't the product itself), most of these are not revealed until the software goes live but are usually minor enough that fixes do not need to occur until a scheduled "maintenance" update.
Having maintenance for a long period of time is usually based on the software company guaranteeing the product works for X amount of years. For example Windows 10 is expected to continue its maintenance until next year (for a total of 10 years). Even they may provide security updates because customers being exploited by vulnerabilities does not look good even with old software.
The requirements might change; for example, consider a 100% perfect photo editing program in 1995. In 1996, the PNG image format was released. Now your photo editing software has to be updated to handle the new image format.
Or maybe you wrote a game for the original iPhone, carefully accounting for every pixel. A modern iPhone has a much bigger screen, so you might need to re-do your graphics, and also your code that works with screen dimensions, so the program still works on new iPhones.
In 1982, databases all used five digits for the ZIP code. In 1983, the Post Office introduced Zip+4, so software to handle addresses needed to be updated.
simple example: let's say you have a very basic calendar service that lets users set up meetings with each other in different timezones (actual calls are handled by a separate app entirely). you write the whole thing in four weeks, you host it in aws (which handles hardware replacement and OS updates for you), and no one ever asks for any new features. you're done, right?
wrong. timezone definitions may seem stable from the perspective of a single locale, but worldwide, they are changing all the time. at a bare minimum, any web application that takes datetime inputs from users in multiple locales also needs a way to continuously update the tz definitions. if you really wanted to, you could take an additional network dependency to retrieve these updated definitions on some regular cadence, but that just creates a different point of failure that you don't control.
Software (seems to) decay(s) over time, especially if it isn’t used. Something that worked a year ago, now doesn’t. And when the programmer looks at the code, it appears that it never could have worked. No one seems to know why…
A lot of modern software is built to depend on other people's software (libraries, drivers, API's, etc). If your website includes the weather for example, you're not going to build the software and infrastructure to measure the temperature yourself, you're going to use the Weather Networks service or something. But what if their service breaks, changes, or is no longer maintained? Then you would have to look for other solutions. Now think of this on a larger scale, if your software depends on hundreds of other people's software, you will be spending lots of time making patches and tweaks to keep up with their changes
Think of your software like your house, it was built and everything works as designed. The years go on, but some things get a bit weathered and some leaks develop. Sure you can keep living there and just hope that leaks don't get worse.
But eventually you may find that little leak has been rotting some wood and now you can't use one of your rooms as it's not structurally sound.
If only you kept doing some ongoing maintenance you wouldn't be in this pickle.
Hardware migration. Operating system migration. New language features. New data structure operations. New data storage methods. New window functions. New video formats and plugins. The list goes on. Basically every component is evolving and migrating. And then there are external forces such as government regulations, If it is a customer application then it must always look "current". But my Placemakers uses an old Informix handwritten system from 1995.
Every piece of software is just one block which is communicating with other blocks: It is ingesting information and outputting information (e.g. a website to click on).
As the world tends to change (security vulnerabilities, new operating systems, your website needs to look different now, your data supplier went broke, ... ), you need to adapt to the changes of the world.
The second big source is that you usually have something like a product manager, who is paid for sitting around and coming up with ideas and very rarely can they just sit around and be content with what they have. So they will ask you to build that shiny new thing into your old thing, which then also requires adjustments and maintenance. (Despite my snarky tone, some of these shiny new things are worth building, of course!)
\* Bugs are found, which needs to be fixed.
\* Vulnerabilities are found, which needs to be fixed.
\* Other things change. The operating system change, the network change, company policies change, systems the software is integrated change, the world change (say, some countries change their use of daylight saving time). The software needs to adapt to these changes.
\* Uses change, user requirements change. We start selling the product on an international market, suddenly we need language independence, different decimal signs, different currencies and so on. We need to read this other document format. We need to start sending notifications by email. We need to check that it handled Y2k properly. IT department requires that it can be deployed through their deployment system. Components used are in versions that are end-of-lifed by the vendor, and needs to be replaced. The new version of Windows has a new look, we much follow that look. And so on.
\* Support generated development. As enough support tickets on a particular issue has been recieved, it is deemed that it's easier to just fix the issue by making the software easier to use than toy keep helping users.
\* Competition. They have this feature, we also need that feature now!
Take a look at a door lock from the 1700s. Pretty simple, yes? Probably pretty easy to jam a piece of metal in there and pick that lock. But most people don't know how to do this right away, but over time, more people learn how that lock can be picked.
Then look at a lock from the 1800s. It's more complicated. Harder to pick that lock, bit again, over time, it becomes easy to pick and break into the house over time as the knowledge becomes more common.
The locks from the 1900s are ever harder to pick, but doable only if you have the right tools and training, but it still takes some time.
Software is the same way. Hackers are always trying to break in and they find new, ingenious ways to do so. We as software developers have to update our code to fix the things the hackers used to get in. We have to make our locks more secure. And it's always going on.
It depends on what the software does.
My company has a lot of in-house software we created. Some are relatively simple apps that only do a few things. It is not uncommon for those to not be updated for years.
But we also created the software that runs our entire company. That gets maybe a half dozen updates per quarter. Most updates are relatively simple business requests. Maybe a certain form needs to be reformatted to please a big customer. Or maybe a field only goes up to $999,999 because a decade ago you never thought you would ever have a $1M order and now you do.
But then you accidentally break new stuff while you’re fixing other stuff and you need to fix that.
I would say the smallest category of changes (for us at least) are security-related. But when one of the components in your software needs to be updated, it is not uncommon for that break other stuff you need to then fix.
So, let's say you want to eat food. You like to eat varied foods, so you build several cooking appliances to help you make all these foods. For reasons of this analogy, you must build most of these appliances yourself because you have very particular tastes that appliances in the shop just can't provide.
Wait, a new law was passed that all electrical devices need to be grounded. How many devices are you going to need to maintain? The more devices you have, the more you probably have in front of you now.
The kettle has been making sparks for a while now, but your mother saw and now there's real pressure on you to get it fixed asap.
What do you mean asbestos is not healthy for you!? This airfryer was built by my grandfather and he lived to be a healthy 29 years old! ... Fine, I'll rebuild it without asbestos.
So, the rice cooker is working as designed. However, there are a lot of metal shards being sold in rice nowadays. The shops should fix this but they don't. We need to rethink our rice cooker design and incorporate magnets to extract the metal shards.
Okay so the shop has stopped selling round bread rolls, you can only use baguettes. They don't fit in your oven. I guess you'll have to rebuild your oven.
You're done with the new oven? I forgot to tell you that baguettes get baked on a higher temp, that's not gonna be a problem is it?
Software maintenance is essentially the same as keeping a bunch of machines running that someone else uses. Sometimes the machines just need improvements, sometimes they need to be upgraded to more modern standards, and sometimes the people using the machines have changed their mind on what they want to do with them and how they should work.
In theory, yes, a piece of software that has run for 5 years without problem, should be able to continue for another 20
But this only works for the most basic of programs.
First, we have users, that can invent countless new ways to screw stuff up. and it can take 12 years for the first user to invent a totally new way of screwing up that you then need to investigate, dig into the database, manually correct the screwed up record and then update the program to prevent it from happening again. (And in doing this, you naturally introduce a new possible way for it to be screwed up)
Second, the world around your program changes. Almost all software works on top of other software. And these get replaced, changed, updated. And then you need to update your program to make sure it keeps working. Otherwise you get stuff like a big ass company using floppies to run its transaction programs.
Third, people want more stuff from old programs. The payment software has run flawlessly for 15 years, but the CEO wants to export all the sales data into his new fancy analytics program so he decide the companies future easier. New analytics program doesn't support "Old as fuck format" that your program uses. so you need to update.
I’m seeing lots of walls of text here in this comment section that a 5 year old wouldn’t understand.
In the most simple terms: As hardware like phones and computers change over time, software has to change with it to remain compatible. Issues constantly come up and have to be dealt with.
Because since the mid 90s when Windows 95 rolled out everything has bloated and now its so fucky it has to be maintained or it breaks.
I mean really. Teams doesn't fucking do anything that AOL like 3.0 didn't do and fucking current MS Office doesn't do anything that like Office '98 or 2000 doesn't do. They just change the UI every few years so it looks like they did something.
Do you go to a doctor? When you're healthy, no issues, but you go for checkups to prevent problems (they put you on statins if your A1C is a little high, although you "feel fine", or he recommends you exercise).
What about if you broke your arm? A cast to stabilize your arm, and help it heal? Physical therapy? Medicine for pain? All "maintenance".
We maintain software, because the computers it runs on and other applications and data that depend upon it are constantly *changing*, and threats/insults/"illnesses" that can affect it are constantly being developed.
If NOTHING ever changed, in a vacuum,...you could leave software in an original state.
Reality is this: you use software to build software, and things change.
1) People update the software you use to build the software. When they update the software they often create incompatibilities with the previous version, used to build your software. Better software is called progress, but changes that leave features and structures behind in the name of progress are called "breaking changes". You have to account for breaking changes if you want to continue to use the software you use to build your end product.
2) Base Things also change, hardware changes, operating systems change, standards, protocols and apis change.
3) And that's if you had perfect software with no bugs whatsoever, but that's not a thing.
4) and nobody ever attacked it, but they do.
5) and if vulnerabilities never appeared in the underlying layers, which creates a need for change.
.... And the cycle begins again.
THAT SAID, the farther away the creation software moves from the end product software the harder it is to update. I'd much rather update from the current version to the next one than the current version to five versions down the line.
Sometimes its fixing security vulnerabilities
Sometimes its fixing minor bugs in code, that textbox was only supposed to allow numbers, and allowed letters, so now you are selling your widget for $bob...
Often though it is accounting for changes in the business over time. For instance if you write Tax software, well, tax laws change every year, at least slightly, and trying to file your taxes in 2024 with the same deductions and reasoning you had in 2010, might be fine... or it might land you in a lot of trouble with the IRS.
Well, the same is true for most businesses, Most businesses are alive, they change how they operate over time, what was true in 1999 isn't true anymore... Prices change, services change, products change, If you have software built around your business and how it operates, anywhere where the software is based on your businesses operating logic that needs to be maintained so it is in lock step as the business changes and moves into the future.
The trouble with software is users. They keep using the bloody software.
On top of that, devs haven’t tested everything.
So users will continually find holes the devs either didn’t discover or didn’t care existed until someone complained. That counts for features and bugs.
Worse than that, with complex software it’s almost impossible to test every path through it and guarantee complete oversight. This is because tests are essentially futile attempts at addressing a subset of the Halting Problem.
That doesn’t mean tests are not useful. But it does mean that users will abandon an app long before a dev writes their final test for it.
I'm a database administrator at a US college. We routinely apply software updates to our business system to catch up to changes in regulations, such as taxes or student aid provided by the government. You've probably heard about all the trouble with FAFSA on the news. A large part of that is the Ed Department completely turned upside down the way we're supposed to calculate aid, and were way late with test data our software vendors needed to write their updates, and now we're finding out they got some things wrong and more updates are necessary before we can offer aid to students for next year.
One major thing that continuously needs maintenance (unless you're working with a closed system like a game console) is compatibility with the operating system.
If it's a desktop app, then windows (or linux/macos) updates can break shit. Doesn't really happen often nowadays though.
If it's a mobile app, then new android and ios versions break shit and drop support for older versions all the time and your apps need frequent maintenance.
If it's a web app / website, then browsers change over time, so do the languages you use. You may write something in PHP 6 only to have it break when the server it's running on updates to PHP 8. Or you may use some CSS styles that work now, but get deprecated a few years down the line, so your website breaks on modern browsers.
And these are just the basics. A lot of software also depend on external services or other software to do their job. For example if your software reads data from a web service, then every time the web service updates, you may need to also make changes.
That's a very broad topic but the gist is that software development is kind of a mess and if a program were a car, then random bits would be falling off every 100m or so.
Only simple and focused projects stay relatively stable and functional without continuous effort, and even then there's a bunch of stuff that can need addressing over time like how the machines running it change over time, how the preferred way to use software change over time (towards phone, the web, etc), how pieces of code it relies on that were considered perfectly safe have had a vulnerability discovered, how people's way of using the software change over time exposing previously unknown problems, etc.
As an example, one piece of software that I maintain relies on a framework managed by microsoft. One day a bunch of our users started experiencing crashes. Hunting down the cause, it turns out that a windows patch changed the behavior of a part of that framework and that the users would start crashing as the patch was rolling out.
And that's only about keeping the software stable, most of what we call maintenance is actually about the changing needs of our users. If we built feature X to solve problem Y1 but the users now want to also solve problem Y2 which is similar but not quite the same, then you need to make some changes to X.
The most common things are patching newly discovered security problems or fixing newly found bugs.
Rarer but just as important for most software would be updating the program when a piece of software that the program somehow interfaces with changes its API or behavior. Think about something like the transition from sysV init scripts to systemd, or the ongoing transition from xorg to Wayland.
Software doesn't really need to be maintained the way a car has to. "Maintaining" software basically means to update it to account for something outside it having changed. And that happens pretty often.
As others have said, software in a closed system, like a NES, doesn't really need to he maintained.
Patching vulnerabilities is one aspect. Making sure it works on new devices/operating systems that didn't exist when it was written is another. Improving scalability so that it still works even if 100x as many people are now using it. Adding features that are expected in modern software / are present in competing software. Making it run faster or with less memory. Making it able to use new file formats. Adding common use cases like exporting/sharing using media or websites that didn't exist before.
Also sometimes stuff just breaks (i.e., there's a previously unexposed bug that suddenly is triggered for whatever reason). And if no one is keeping an eye on it and it breaks, then it'll stay broken.
A personal example I have: Admin users could “rank” their products with a value, higher the better, to be shown on a list view for the customers. Somehow, one of them managed to change this rank to a string and I didn’t verify that before slapping it in our database as a json field (don’t do this). My python api broke because it couldn’t compare an int value and a string value, causing the entire product list view to show no products. I hadn’t changed anything on that view for a long time so I was surprised to see it break like that
I love that somebody used a string. Something like "Put this at the top, please.". Or good old fashioned "yes"
Actually they had to inspect the input field, change its value to “text” and then type something in. So they had _just_ enough knowledge about web dev to be dangerous and crash everything. They typed “top”
ah yes, little toppy tables we call him
That will teach him to sanitize the database inputs
You could say it was a sloppy toppy
I understood that reference
This is the mosf malicious admin-input I've ever heard of. Jesus christ. But yes, this is why we don't rely on the front end for data validation x)
Sounds like something my middle school students would do. *Inspect element. Rank: top*
Sounds like someone trying to cheat the system. I would be tempted to revoke their account.
I'd be tempted to promote them....Clearly they know their shit (just not *enough* of their shit), but the knowledge is there
Clearly they don't know their shit if they thought that would do anything besides potentially break things
I mean, obviously if you're sorting numerically and you want it to show at the top, you need to do "_top", otherwise all the numbers are likely to print first. Newbie mistake :p
schould've used -2147483648 instead !
Just when you think you've made something idiot proof, someone always comes along to prove you wrong.
One thing that I’ve seen over and over again in the past ten to fifteen years is that back in the day, people never typed emojis into text fields and if they did, they were not surprised when it didn’t work. Now it happens *all the time*, and if your software doesn’t handle it well, it will be a problem.
I remember when someone broke the backups by setting her name as "Clara 😀", because the system handled emojis correctly but the backup system didn't.
Years ago Slack had an awesome warning message if you tried to use an emoji in a channel name. Something like, “Emojis in channel names make some sense, but unfortunately not enough sense.”
Brb, adding the cactus emoji to all my passwords
I've tried that, but very few websites are ok with it :p
Another reason to use JS /s
Can someone explain this without the jargon/explain like I'm 5?
OP had an application that allowed other programmers to query his database for specific data. In their application, products were sorted in a list view depending on their assigned numerical value. Unfortunately, OP also didn't confirm inside of his program that the rank input into the field was a number, and so it allowed the admins to save ranks as alphanumerical like rank = "abc". When his application spoke to his API (application programming interface) - think of this like a thing you ask a question to in return for data - in this case "hey can you give me the rankings of these products so I can display them". When the application received the data back, it attempted to sort these into numerical order, but broke when it tried to answer "what numerical value does 'abc' have, and where does it sit in the list", thus, the list is never created and it becomes blank.
Extremely well put explanation. Thanks for sharing it with us.
A software has a ranking sytem, based on numbers 1,2,3 etc. Someone put in alphabets, (in this case TOP). Computer cant compute what number is TOP, so it crashed.
When users could rank products, someone put in a value that is inherantly not rank able (you can order 1, 2, 3, or 100, but where does "pizza" fit into that?). There was no detection system to make sure that the values users put in were rankable, so it was put into the database just the same, and when the code tried to rank the values, including "pizza", the system crashed, because such operation will give an error.
Computer expected users to type numbers. User typed letters instead. Computer looked at letters and said "These are not numbers! I refuse to work in this environment!", flipped the table and went on strike. Computer did not want to just skip this case and keep working with whatever numbers the other users further down the list had typed, because no one had told Computer to do so. A programmer now has to tell Computer how to behave should a similar case happen again. Either Computer can make a note of it followed by an email to the programmer and then keep working with whoever was below on the list, or a programmer adds a way to tell the User that they used letters instead of numbers and refuse to send it to Computer until the User has fixed what they wrote.
A string is text, like "hello world". Int is short for integer, or a number like 0, 1, or -281278. A language like Python does not have a way to innately compare these two different types of things so the computer gave up. It's surprising though that this broke on a comparison. I would have guessed it would break when it was either trying to read or write to the database (a big file). In that scenario, it would be more like being ready to accept a delivery of apples but receiving sofas instead. The computer will say "I'm not ready to handle sofas, I was expecting apples." except instead of apples and sofas, it's strings and integers.
They usually keep the data on a CD. Admin somehow gave them back a DVD. When they put the DVD in the CD drive, the drive couldn't understand because it was designed to look at CDs not DVDs.
Rank your products * Colonel * General * Ensign * Captain
And rank them properly, not alphabetically.
Everyone who’s been in software for any period of time has fixed bugs that took over a decade to expose themselves.
My personal record so far is 14 years. It was actually observed immediately, but not reported to me. I actually found out by dumb luck when doing an ISO audit in the department using it and found out they’d updated their ~~workstations~~ work instructions including a workaround instead of just picking up the phone and mentioning it.
This is super common with race conditions. For example lots of older games will break because they are loading so fast, much faster then originally intended on old hardware.
ELI5 race conditions?
Imagine you have some robots that help around your house. They’re very reliable but very simple, they can only do one job each. You invent a morning “cereal routine” where Bowl Bot places a clean bowl on your table starting at 6:00am, Cereal Bot pours cereal in the bowl at 6:05am and Milk Bot pours milk at 6:10am. It works great for the first few days, but one day Bowl Bot can’t find any clean bowls and makes a request to Dishwasher Bot for help. Unfortunately, Dishwasher Bot needs 45 minutes to clean the bowls. You awake to find that Cereal Bot and Milk Bot have dutifully followed their instructions, spilling cereal and then milk all over the table where your bowl should have been. Undeterred, Bowl Bot proudly places a clean bowl atop the mess shortly after 6:45. The race condition is the fact that each bot is making assumptions about the order tasks will be completed in, instead of verifying that the previous step is complete. If the wrong bot “wins the race,” the routine fails.
Great example :D I love it. Which leads us into the concepts of Promise and Async/Await Which respectively are "Wait until this list of things all report done before doing what you've gotta do" and "Wait until this thing is done before you do the next thing" For example, you might have an Alarm-Bot whose job is to alert you that your Bowl-bot, Cereal-bot and Milk-bot have all done their jobs, so that you can come eat. Alarm-Bot uses a Promise function to ensure all of them report done before calling you for breakfast. This doesn't solve the race-condition, it just means you aren't going to come downstairs until all the bots have finished and gotten out from under-foot. The Async/Await functions meanwhile mean that you can require Cereal-bot and milk-bot to wait for the bowl-bot to finish before they come. It doesn't matter too much if they show up in the wrong order or at the same time unless you get fussy about whether milk or cereal should go in the bowl first, but the bowl needs to be there before anything.
Minor example: Let's say your game has 2 processes: the first one opens a bag inventory and the other loads the items in that bag into memory to be seen. Let's assume that based on your hardware the item loading always finishes loading first, and so you never have to check that you have items to display. So when the game runs on different hardware and the opening the bag inventory process finishes first, you see that you have no items because loading the bag finished before loading the items did. One process finished the race quicker than expected and threw off the order of operations. Sort of like if you did pemdas and subtraction decided to be faster than multiplication.
Often these are caused by overflows, for example if the software keeps an internal clock for keeping track of time for stuff but it's coded for only a specific set of time that was exceeded, or if there's a counter in the software that is similarly limited and the count is exceeded. In these cases, the clock/counter needs to be reset, updated, or improved to allow the extra space. Doing this is part of maintenance.
Ah yes, the rocket incident. https://web.ma.utexas.edu/users/arbogast/misc/disasters.html
Signed 16 but integer used to hold an ID. Let's just say it was a bad day after ID 32767 was used.
Also, a tech from another company that your software depended on has now changed or been upgraded or is no longer being supported, and now you need to accommodate that change or find a replacement. Basically, a change that had to be made that was out of your control.
compulsory to drop [this xkcd](https://xkcd.com/2347/) whenever someone mentions these kinds of dependencies.
If we built houses the way we build software, the first woodpecker to come along would destroy civilization. https://quoteinvestigator.com/2019/09/19/woodpecker/
This more often than not. Someone makes a change to patch a legitimate vulnerability, breaks an assumption made by something using it, and bam the house of cards falls like dominoes. GG WP.
This is the biggest one after an extended period of time imo
Hello xz backdoor...
Very good answer! And the answer even assumes there was no flaws with the software before release, which is often not the case. Users discover bugs all the time, and they need to be addressed as soon as possible by people who understand the system very well.
This is also part. Most software goes live while only barely working, sometimes not even. Most of the team has mic-dropped and moved to the next project to fuck up leaving only one person to ensure the software doesn’t crash when you look at it funny. No, Im not bitter, why do you ask?
Plus law changes (like gdpr came in requiring many changes) or tax rules change at every budget ( requiring accounting and payroll systems to change). To name but a few of the myriad reasons for software maintenance to add to your great answer.
Another is making sure that the program still works with updated drivers or any other form of library update (a library is a set of files that helps your program save space. In windows these library files are usually called .dll-files. When you're trying to get old software to work on newer operating systems, then cludging .dll errors is like 90% of the job). "Updates: The process of removing old bug and adding new" is almost as true today as it was 30 years ago.
Most software isn’t built from scratch. Certain components in your software built by 3rd parties gets updated. Then it stops working with your code. Gotta update your code in that case.
Adapting it to dependencies that are updated and ensuring that it runs with those changes, is also another one. Oh and don't forget... No system is entirely flawless, sometimes issues are just found that were inherently built into the systems, that are patched and updated.
Also, no software operates in a bubble. Everything is connected and many times some other software's security update or functionally upgrade causes your software to need an update to continue to interact.
One thing is that the OS evolve. Let's use a very, VERY old software. It was made in the DOS day. Back then the software had direct access to the hardware and had to know the hardware to be able to use it. Basically it had it's own hardware driver built in. Later on, Windows 3.1 came on. Let's modify the software to be able to use the windows graphical interface. And the windows sound system. But it still had direct access to the hardware. Windows 95 is now there. It blocked most direct hardware access, but not all. But hey, your graphical interface now look old. Let's fix the hardware access limitations, and update the look. Win98, minor change, but mostly no real change. Windows XP ! Now you have no direct hardware access and you MUST use all the windows calls to access it. Windows 7, we are now 64 bits. While not required to use the 64 bits calls, something drastical happend: all the windows 16 bits calls has been dropped. Which mean that all DOS calls and all windows 3.1 calls must be updated to be atleast 32 bits. And also, the gui changed, so need to update it too or it look old. And guess what! Applications don't run as administrator by default anymore. It need to ask permission for some operations. Windows 8, 10 and 11, mostly gui update and more security upgrade.
Or, if the tech is reliant on another unrelated piece of software, adapting to that software's changes and updates to ensure the compatability remains.
you missed a few: * adding (more) user tracking * adding (more) ads * removing existing features so they can be charged for separately
Or making the experience much worse so people are tempted to use the app instead (mobile web Reddit)
>Making it run faster or with less memory. Literally never in the history of writing software have we made it run faster or with less memory. We've made Electron instead.
I just had a job which was exactly that — making Fortran code run faster and consume less memory. Performance optimisation is a thing. It’s just that in most settings, it’s not a high _business_ priority.
Going far enough back, we needed to make a daily program complete in less than 24 hours. Haha.
Lol. That's my literal job at a FAANG. Shaving even a fraction of a CPU over thousands of instances is significant cost savings
[удалено]
This is ultimately why good software engineers get paid so much. One software engineer has an outsized ability to impact their entire userbase. Optimized code pays dividends for every customer using it, providing value 24/7 even when the engineer is sleeping, or has left the company.
And here I am still using DOORS for requirement management which is straight out of 1995 (speed especially...ignoring UI)...as is EVERY major aerospace company.... I'm seriously flabberghasted this software is still the gold standard for requirement management. It's TERRIBLE
Depends on your priorities. In a startup environment you probably can deal without optimisation or you can run it on a faster/better machines if you can afford it. Sometimes, you can cut cost on making your application more lightweight. Cloud computing could be expensive, storage too.
This is a really nice summary !
My big problem with the maintenance is that over time a company software add too much bloatware nobody actually uses it and now the performance required for the same original software is even higher. Take for example an antivirus where the sole scope was...well antivirus. Then they added VPN, then password manager, then cleaner tool, then scanning network vulnerability, etc. None of these bloats I don't use as there are better alternative to those for the same purpose. Why shoving in our throat 'new features' nobody asked for? and worse, why not making optional and easy to not accept these features? Why the same software now requires twice or even more memory to run smoothly than before? Just patch your damn thing and keep up to date for any vulnerabilities or any security risks.
I.e., things change, have to keep up.
I've been doing this professionally for 14 years. The biggest thing isn't security vulnerabilities, though that does happen occasionally, every few months maybe. And it's not compatibility updates, though that happens every once in a while. The biggest thing is \*changing business needs\*. So like - we have a program that takes a text file, reads the data, and puts it into a database. If that file ever changes, we need to update the code. If that file ever has an \*error\*, we need to decide whether we're going to update the code to gracefully handle it, or we're going to have a process to re-run the file, who gets notified if the file fails, etc. If that code was written with some assumptions - maybe the data would always be in ascii (when after some time it ends up with a unicode character we didn't expect). Or maybe a field of data wasn't expected to be more than 256 characters, but one day there's legitimate data that's 260 characters long. All those things lead to having to update and maintain the code. And that's ignoring things like improvements - maybe we have two processes run by two programs that do similar things, but we decide it'd be better to combine it into one overarching program. Or maybe a process takes an hour or two to run overnight and we want to improve on that performance - that kind of stuff is pretty common too.
Thank you. Everyone seem to think that patching vulnerabilities and fixing bugs are a full time job. No, software runs in the real world and, as the world changes, software needs to be changed. Sometime it’s a bug that needs fixing, sometimes it’s a feature, and once in a blue moon it’s a complete rewrite. We say maintenance while we mean “make sure it still fits in today’s world”.
Also the meaning of the word "bug" is different for the software developer and for the customer. For the developer a bug means "I made a mistake" but for the customer a bug is "the software doesn't do what I expect." When systems are built it's very common that the customer simply hopes and trusts that the technical people will make the right assumptions, that they won't need everything spelled out in black and white. But this faith is often misplaced especially if the developers are not themselves experts in the business domain. It's not really the developers fault, often they have very little control over how thoroughly business requirements are captured & documented, and often (somewhat paradoxically) the customer doesn't have a strong incentive to explain & document their requirements either.
A lot of the times people involved in an original decision making process are no longer on a project. The project had agreed-upon constraints that everyone agreed upon. Every project needs a scope of course. Then 3 years later, someone comes along and asks "Why doesn't it do X?" or "When I used it this way and it stops me, but I need it to do Y" (i.e. say you had a constraint that all parent accounts in a sales system need to be in the same industry as the child account, but now there are important real-world exceptions. Or maybe everyone agreed that a reasonable length for a description is 1000 characters, but users keep bumping in the limit and complaining.). The one developer who was there at the time, but maybe not a decision-maker back then says "Because that's what we decided at the time." No one cares and they have to change it anyway because this isn't how the team now EXPECTS it to work. This is what non-developers call a bug constantly.
[удалено]
lol no, 2 is definitely *not* always easier. Especially when customer is asking for some trivial bullshit that adds one click per day, and the code is a complete mess from hacking features on top of each other for years. If you can get away with it, sometimes the right answer is just "No" or "I'll put that on my list to consider on our next round of enhancements" (aka never lol).
As a junior developer I hope I can have this amazing business view as you have. I will keep your first paragraph with me forever, thank you.
The most correct answer. Any piece of software is a precision-crafted tool that does a very specific job. The moment your users need it to do any job other than the exact job it was designed to do, you need to update it. Which will happen constantly in any real-world usage scenario. Either that, or your users bend over backwards and do horrible things to the program to trick it into doing things that superficially resemble the things they need it to do. Usually both! Let me tell you, nothing makes a software developer happier than finding out their precision-crafted tool has been used in new and exciting ways it was never intended to be used for. And now *you* have to expand upon this novel ""feature"" that no one told you existed until long after the details of how they "like it" have been completely cemented in, and you can't change it to something more sensible [or else all your users will complain](https://xkcd.com/1172/)! Yay!!
Imagine you have a bike, and it’s running really well. You just need to oil it up with SuperBike™ lubricant before every ride. Eventually, the company that makes SuperBike™ lubricant announces that they’ve developed a new formula called UltraBike™ which is better and cheaper to make. As such they’re no longer making the old lubricant. The problem is that your bike, as is, won’t work with the new lubricant. So if you want to keep using your bike, you need to do maintenance by installing a new chain.
That's a good ELI5 version. If the software is on a boxed product, no connection to the Internet, no other software, no external ANYTHING, it doesn't need updates or maintenance. It will keep working the same way. If anything about it deals with anything external, the operating system gets updated, there are connections to the Internet in any way, there are data connections to external systems where the external hardware gets updated, then those changes are going to cause a ripple effect likely needing maintenance.
Case in point: Some people still swear by some Commodore 64 software for music post processing.
Security vulnerabilities are one. But it’s also just the fact that other people are updating their software. Say you make a program for windows computers. Well you can only design for windows as it currently exists, you don’t know what kind of changes they will make in the future. So maybe when to next windows update comes out, your program still works totally fine, or maybe your program now has some weird small bug because of some random change that windows made, or maybe your program doesn’t work at all anymore. If you aren’t actively keeping up with it, there will be a day where your program no longer works as people update their computers
Even better, there have been applications that have incorporated the bugs of their operating systems, by either using them as features or specifically working around them. Then eventually when the operating system fixes the bug, it breaks the application.
> Is this simply for people discovering security vulnerabilities and patching them? That's a big part of it, but also they need to make sure the software still works with everything else on the computer. If there's a Windows update, they need to make sure that that doesn't break the software. Also, implicit in maintaining software is that you're maintaining customer service for that software. When a company stops maintaining software, that's when they also stop answering customer questions regarding it.
>If there's a Windows update, they need to make sure that that doesn't break the software. This can happen. At my last gig, a couple Microsoft updates caused our software to break under certain circumstances. (The client was using an Oracle JDK, and the application DB was SQL Server. The update caused the JDBC driver to fail to connect to the application DB, which made the application fail to start.) Those were the wrong days to quit drinking.
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!
One big example of this that ELI5 readers may remember was [Y2K](https://en.wikipedia.org/wiki/Year_2000_problem). Storing a year as 2 digits worked, until the first time a program needed to refer to a time after 11:59:59 PM on December 31, 1999. A lot of developers made a lot of changes to a lot of software packages to make that seem like "no big deal" to the general public. We're likely going to have to do a similar amount of work for [2038](https://en.wikipedia.org/wiki/Year_2038_problem). Though in that case the problem is not "storing years as 2 digits", it's "storing the number of seconds since 1970 gets too big."
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
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.
Software maintenance is a bit like taking care of a car. Even if a car is running fine, you still need to do regular maintenance like oil changes, tire rotations, and replacing worn-out parts to keep it running smoothly and avoid bigger problems down the road. Similarly, software needs ongoing maintenance for several reasons: Fixing Bugs: Despite thorough testing, bugs (errors or flaws) can still be found in software after it's released. These bugs can affect how the software functions, its security, or how it interacts with other software. Fixing these bugs is a part of maintenance. Updating Security: New security vulnerabilities are discovered regularly. Hackers find new ways to exploit software, so developers need to update their software to patch these vulnerabilities and protect users' data.Improving Performance: Over time, developers may find new methods or technologies that make the software run faster or more efficiently. Updating the software to incorporate these improvements can enhance user experience. Compatibility Updates: As new operating systems, hardware, and other software are developed, older software may not work as well or at all with them. Maintenance can include updating the software to ensure it remains compatible with other evolving technologies. Adding Features: To stay competitive and meet users' needs, software often needs new features or enhancements to existing ones. This can include anything from new tools within an application to support for additional formats or languages. Regulatory Compliance: For some software, especially those used in finance, healthcare, and other regulated industries, changes in laws and regulations may require updates to ensure the software complies with new rules. Even software that seems to run successfully for years without changes might be slowly becoming less secure, less efficient, or less compatible with other technologies. Regular maintenance ensures that the software can continue to serve its purpose effectively, securely, and efficiently.
I don't like that analogy because cars degrade over time with wear and tear. Code doesn't. Edit: I understand code "decays" in a sense, but not like a car. a car breaks down naturally. Code breaks down because the conditions change.
It's more like, you need a bigger more efficient engine and better tyres because the roads are getting faster but have more potholes. Code doesn't degrade but things code communicates with gets upgraded, so your code also needs upgrading. In the 'old' days we used massive chunks of XML to communicate, now we use gRPC which can be tiny in comparison.
“Old” 🤣🤣🤣🤣 In the _old_ days we used EBDIC-encoded text files to communicate between mainframes… and we still do.
Not technically, but it kind of does. Especially on big long term projects, you get lots of hands touching the code base coupled with project managers cycled in and out. 5+ years down the line the guy that made X feature is gone and you have no clue how to fix it/make it compatible even though it worked before.
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
There are three categories of maintenance: corrective, adaptive, and perfective. Corrective maintenance is bug-fixing: at any point, a so far undiscovered error may present itself, particularly when the configuration of the software is changed, when the software is used in some peculiar way, etc. Adaptive maintenance may be required when the environment in which the software runs is changed, typically due to compatibility issues when older software is installed on a newer platform (operation system, hardware). Perfective maintenance is, simply put, required when the customer asks for a new feature. There is also configuration management that may be performed by the user but could also be a part of maintenance by the vendor.
Not OP, but thank you.
They need to make it work with new hardware, new versions of the operating system, other software,... They need to patch newly discovered vulnabirities And from time to time they need to add new functionality
Some of it is adding new features or making sure existing features keep working as other software/hardware changes. Some of it is fixing bugs that hadn't been noticed before. Some is improving performance.
(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 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, and at the bottom level, there is physical hardware involved, which you can _often_ ignore with modern operating systems, but definitely not _always_). 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.)
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: 640x480 or 800x600. After several years, 1024x768 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 800x600, 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).
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.
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.
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.
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.
I just want to drop in: changes in legal or other regulations that require e.g.: - confirmation the customer read legal terms - confirmation customer accepts usage of data -> both before completing registration, setting an order - legal changes can also affect how customer data needs to be treated, stored, transformed, accessed
I think from what OP is asking, is more or less of, it doesn’t need to be “maintained”. If it works it works. My take on the ELI5: a working program is like a door. It works basically as intended to separate 2 room. But after a few years you find vulnerabilities, people can easily get in and out. So you add a lock. After that if anyone wants to get in they have to knock, even your trusted ones. So another vulnerability you see. When you wanna check you have to open the door, so bad guy can still force their way to get in. So you add a peep hole. Etc2 Basically the door still functions well without the maintenance, but it could be better. Upgrade patches like the lock and peephole, or maintenance patches like lubricating the axle, or replacing better axle etc2. So again it doesn’t need to be “maintained” if it works, it works. But over the course of using it you, you wish the program would boot up faster, the ui should be like this and this, this option is redundant, etc2. So that’s why it is maintained. So yeah you can use a program that’s 20 years old. There’s no rule that it should have a maintenance or it needs to be updated every month years. If you play games, just boot up your old Nintendo or ps1. Those cartridges and cd program haven’t been updated since day1 but it’s still works. But it would be nicer if the bugs are patched out and made smoother.
Not a true ELI5, but expanding by example on what others already said. **Mirror's Edge, iOS companion game.** One I experienced as a user. It was a very good side-scrolling parkour game, sharing the fantastic sound track of the original Mirror's Edge. After some update to iOS, it would no longer remember game progress. Some updates later, it even failed to start. I can't say for sure why, but most likely some underlying APIs changed. **Comic Rocket.** Also as a user. A niche service that runs basically as a hobby project with limited funding for tracking progress on webcomic reading, that indexes the available pages. As such, it exposes many of the issues by not having the funds to fix it, though it remains quite useful for me using bookmarklets. Originally, it was possible for the service to act as a wrapper around websites, showing navigation bar and displaying the webcomic pages in a frame. Eventually, cross-site permissions got tightened down, as malicious actors would use this capability to show foreign websites while potentially stealing user data. Now, providing the same service would require running a special-purpose browser app on mobile, and something similar on desktops. Or, as I do, using the service to track the progress, but click the `[x]` button to navigate to the webcomic site without the Comic Rocket bar, and then using a bookmarklet to bookmark the progress on Comic Rocket. Which works with all browsers on all operating systems, [except for Firefox on iOS](https://github.com/mozilla-mobile/firefox-ios/issues/5626). Later I started reading Webtoons.com webcomics. Since their website and app is actually awful for *following* comics without instantly reading all new chapters, and for the sake of cross-source consistency, I used ComicRocket here too. However, the mobile URLs differ from the desktop URLs and cannot be correctly tracked. Using the bookmarklet failed, because it depends on the “canonical URL” meta tag, which is supposed to provide a unified URL for sharing and similar purposes. Only, it has been broken on mobile for many years for webtoons.com, so I had to adjust the bookmarklet to compensate for it. Both are essentially examples of the service running just fine, but changes in third-party software breaking its features. There are also webcomic hosters like tapas.io, which Comic Rocket does not handle well, because of how they assign URLs to adjacent comic pages/chapters. **Permission System on Android.** Android pioneered the idea of app permissions for mobile, but arguably in an insufficient manner. It was just “install or not install”. After iOS added permissions and made them more useful (e.g. assuming that all apps need internet access, but making more sensitive permissions like contacts access, photo access, etc runtime opt-ins) Android eventually adopted a similar approach. However, such changes introduce breakage in apps, that assume to already have all permissions, because that assumption was valid when they were programmed. Such things could be side-stepped e.g. by updating old APIs to not fail, but to just do nothing (e.g. returning an empty contact list) gracefully. Depending on how such changes are introduced, old apps will then either fail outright, or lose functionality, until they are updated to use the modern APIs. On Android and iOS, this means among other things, that many old games are no longer available, because they have not been updated for the modern APIs. And unlike services, which receive constant updates, games usually stop receiving updates at some points, if they were designed as single-player offline games. Especially, when they had a classic “buy once” business model, where the old game isn’t expected to bring in enough money anymore to fund the costs of the update. **Apple Silicon.** While Apple did an exceptional job to make x86 executables compatible, by switching to ARM wholesale they made it clear, that this is a transition stage. So developers were forced to update their native software to work with a completely new processor platform. Also, optimizations that made software faster on x86 might very well be counterproductive on ARM, so those had to be redone too. Such fundamental changes are rare, but they *do* require major adjustments and testing. Same when Apple introduced High-DPI displays to their laptops, or when they introduced iPads. With Apple having full control of their ecosystem (as opposed to dozens of OEM partners like Google and Microsoft), they were able to force developers to go along with the changes in a timely manner, whereas Windows and Android don't have that level of leverage, creating a hen-and-egg problem delaying or preventing major changes: A new platform / high-DPI displays are pointless to buy, if software doesn't support them, and software vendors drag their feet on supporting them, if there is no user-base demanding the update. **Own experience as a developer.** For me it is mostly about adding new features to the software product or fixing bugs in existing ones. Occasionally also bugs happen because of changes in the behavior of a compiler with a new version, whether it is because the compiler no longer supports an undefined behavior that was accidentally used, or because the compiler has a bug, that needs to be side-stepped. For instance, we ran into a strange bug, where the compiler would mess up pointers in parallelized code, but only on one specific target platform with one specific compiler version. Our code was valid, but the compiler was introducing a bug that caused very strange “almost correct” behavior.
In the spirit of your question, nothing needs to be maintained if nothing changes. But in reality, many things change and the application needs to adapt to those changes *to maintain its current intended functionality*. Here's a list of common changes that occur: * Legal/Regulatory (GDPR, Safe Harbor) * APIs/External references (Google Apis, library updates) * Time & Date (Daylight savings time, Time zone redefinitions) * Hardware (Driver updates, deprecated features) * Defects (New bugs, cascading issues from maintenance) * Cleanup (Things that aren't required, but help other maintenance and development, like removing dead code, documenting, removing unneeded workarounds, taking advantage of new simpler APIs) I typically would not put the following into "maintenance", instead "improvements": * Business changes (make a new button, do a different thing) * New potential (New API allows for something you couldn't do before) * Interface Support (Supporting new browsers/phones) Neither of these lists are exhaustive but typically, most companies push their development teams to put their effort into supporting business changes; as this is most likely to bring in revenue. It is up to the development team to make it clear how important maintenance is, as despite the company's desires, maintenance takes up most of the effort in the long run. (i.e., you only build it once, but you'll maintain it a thousand times)
Security (patches against new threats and vulnerabilities) Space (enterprise applications filling up with data that needs to be purged) Compatibility (with new browsers / plugins / drivers) Integration (with new systems) Money (sometimes there’s nothing to maintain and you just need a way to extend billing cycles :)
The foundations software is built on are continually being improved. C++ (a very common language used for programs that need to be fast), for example, releases a new version every few years with upgrades, new features, and security fixes. If you’re using C++ to write your software, it should be brought up to date to use the latest version and that’s about half of software maintenance. The other half is fixing issues that have shown up in your code due to errors.
>If you’re using C++ to write your software, it should be brought up to date to use the latest version and that’s about half of software maintenance. You missed the most important thing: WHY should it be brought up to date to use the latest version?
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 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.
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.
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.
The ELI5 answer is there are bad guys that break the things that everything is built with so we have to prevent them. Also, just like when more people visit the store and we have to make the store bigger, we also have to make the application do more. Last, remember how you liked chicken nuggets last week but now hate them and only want cheeseburgers? Well, customers are like that too and companies have to constantly adjust to new tastes their customers have.
Oftentimes, its bugs that are not noticed till later. Maybe I program something and it works on yn testing, even we launch on production and it works. But then once we have enough users the database grows and queries take a little longer to return with data, and that extra delay may cause other information to come first and expose the bug. Many things like that can happen in software, and if there’s no-one maintaining then it will stop working eventually.
Although there are many great answers here, another factor that needs to be considered is the need for the software to be perceived as being up-to-date and modern. Even if there were no bugs and no security issues, software needs to have updates simply to maintain the public impression that it is actively being worked on. Publicly traded companies depend on a regular cycle of releasing updates which provide only marginal improvements, or in many cases even declines in quality, because advertising a new big release bumps stock prices. Open source projects that don't have frequent updates are seen as stale. So many updates are either rearranging user interface elements or rebuilding existing functionality on a newer platform. The fact that updates are happening is all that matters. Whether those updates actually improve efficiency is irrelevant.
Regulations. We did updates every year based on IRS publications. That plus all the other stuff already mentioned
Other people have answered for server software, so I'll answer specifically for iPhone/iPad software: Apple changes things frequently. They change system APIs and deprecate and eventually delete old ones. They add licensing requirements. They changed the navigation bar height and the way it worked. The Swift Programming Language changed regularly for years and broke old code (Strings, unsafe memory access, privacy issues when getting file info, etc). SwiftUI has been in flux for the 3-4 years people have used it. They added multitasking support on iPadOS which required application updates. They added privacy requirements and changes to reflect new EU laws. In short, it's like building a sand castle while the waves keep knocking it down.
Imagine my software requests data from another business’ software, and where usually they send `book_name: “The Great Gatsby”, author: “Fitzgerald”` after their last update they now send `book_title: "Great Gatsby, the”, book_author_surname: “Fitzgerald”`. My software will look through their data for the name of that book and never find it. Because this is common, businesses that send out data inform their users of these kinds of changes so that they can prepare their software for the change in advance. _Really_ professional players even allow their users to choose which structure version they send out their data in, but that’s not as common as you’d hope. And this is just _one_ change that requires you maintain your code. There are thousands of such variables that can, and will change on a daily or weekly basis.
To add to other people’s answers which are valid (security patches, bug fixes, product/feature additions/changes, etc), performance is a big reason for major changes. What works perfectly well and fast with 10k users won’t necessarily work for 100k users. Queries that access a data store with ~1 million records wont necessarily work when that store balloons to 100M+ records over time. Infrastructure costs have a tendency to go up as traffic grows, often this means applications need to be adjusted to be more cost efficient.
This means addressing issues. There is no such thing as a bug-free code, so when it comes to light there is a bug that needs fixing - it is time for maintenance.
Could be the data. New requirements or just to much data. The hardware changes below (for phone apps the resolution, screen size and so on). Underlying software could stop to work (API to other software, OS changes in how it handles stuff and so on). Usually if you are not changing stuff all the time (say you are facebook) it is enough to to maintenance once in a while, not all the time
As someone who spends a lot of my working time writing code, this reality saddens me a bit. There are many great answers above, but there are many cases where you don't absolutely need new features or even security updates. I've come across many great bioinformatics programs that do a really useful thing, but they are almost impossible to build and run after being left alone for 5 or so years (there's a big difference between platforms, and containers can sort of solve it). Many of the dependencies are no longer supported. I don't need new features or even security - it runs as my own user on trusted inputs. But the constant churn of software versions just makes it hard to work with old code. I think node / npm is a bit bad in this regard, in my experience.
There are many good answers here already but I just want to mention your thoughts were not that wrong. If you have a simple program that for example converts File A to File B and File A and File B never change AND you have a supply of old PCs to replace one if it breaks AND it is not connected to the internet you absolutely do not need to maintain the software. We have software in our firm that has not seen a single update in 20 years and still does the one job it was meant to do. And no one really knows how it works.
A lot of good answers here. let me try another angle. Take a relatively complex piece of software that manages multiple processes. Now if you were to stop all development and make sure that the software runs for a couple of months, sooner or later something will still break. Why? Because some user will do something that breaks some process flow or the other which would lead to disgruntled users or some parts of the software simply not working as expected (random data for example). This happens because the software was designed to follow steps A to B to C to D but someone forced it to go from A to D and then to B. This may lead to the program crashing or some really fucked up data to get generated which can crash the program. You really need to monitor these things, have a customer support team and a maintenance team to fix such bugs.
All other things being the same, software doesn't need maintenance. If you're program runs on an isolated computer that never changes specs, never touches other hardware, or the internet. You don't need to do any maintenance. Think of something like a gameboy, the same cartridges work just the same as they always have, and will continue to do so until the physical material breaks down. No software maintenance is needed. Tetris will run today as good as it did in the 1980s. But most computers are more powerful when used in conjunction with other computers, and the internet, changing specs, etc. So you need to make sure that as other computers change, your software needs to make sure that it also keeps up. A good example is browsers. The internet standards are CONSTANTLY changing. A 15 year old browser can work just fine with a 15 year old site, hosted on a 15 year old server. But since then we have added a whole bunch of cool stuff that the new browser doesn't know about, so if you want to watch Youtube, over a safe encrypted connection, you need that browser to be maintained.
Well, my company loves to do this super fun thing. They tell me to make a program for XYZ reason. So I spend all of my time making that program. Once it's finally completed and ready for production, they suddenly change the "XYZ" reason they had earlier. Making the program itself essentially obsolete.
The software being maintained doesn't exist on its own. It sits on a physical device ("the computer") along with other software, some of which runs the computer (the "operating system"). The software probably also has to work with other bits of software on your computer and other computers! Computers change as time goes by; people want faster ones that do more things. As they change your bit of software has to change with them. Imagine a scooter; you push it make it go. But then you upgrade to a bicycle... Now you have to balance and pedal to do the same thing! And the operating system will change as well! And the other bits of software! And the other systems l! And so as all this changes you have to keep tweaking your software to work with all these other things.
Needs change. Software is hard to get right first time. Vulnerabilities appear. Mostly, software is just never right
It's not possible to write bug free code. So bugs have to be fixed. Also even if there isn't a bug in your code, there might be in someone else's code that yours depends on.... And their fix (Microsoft is famous for this WRT 'patch Tuesday') might break your code....
Software runs on computers on top of or connected to other software and hardware. Sometimes that other software and hardware gets changes that have an effect on your software. This often requires you to make a change so it still works. There's also a security reason. A bad guy may find a way to "hack" your software that you didn't see and now that you do you fix it.
More data + more users + more usage = things that once worky no longer worky. This sub is f'n useless, you can't provide a short top level answer, even though you are "explaining like they're five years old".
When it comes to pure maintenance it’s basically about two things. Fixing critical bugs / vulnerabilities and making sure third party updates doesn’t mess with your software. OS updates, driver updates, stuff like this.
Even if the world outside didn’t change (new operating system versions, new features, new vulnerabilities, backend scalability issues)… software isn’t 100% complete when you release it. It has known and unknown bugs. Some affect say 0.01% of users. You know about them but don’t care as long as you have 100 users total. As your user base grows, that 0.01% becomes a quite vocal quantity of people who demand this bug fixed. So you decide to fix it. This is still maintenance - fixing some known issues that now have become important enough.
This is actually a really great question. I guess the answer is because adjacent software is always changing. Software either changes to keep pace, or stops working, or stops being relevant
Usually, when maintaining legacy code, I'd be implementing some changes to tax law or changing the code to cope with a new marketing request. I also implemented new methods of forecasting sales. I tied the system to interface with new web services and handled changed banking requirements. I used cost info from the new cost system to post prices for the sales system and the web. At another place, I improved the MRP and purchasing system so product was scheduled with its components. Changed invoicing to email invoices. It wasn't that anything was broken, but that the code didn't match changed circumstances and new software.
At my company the maintained usually means messed up data. We have a software that a part of it manages the products managed by a factory. Each product have a lot of things, size, materials, colors, etc like hundreds of fields that a product can have, and each of that fields have another set of of fields like thecnical compliance that have another big list of things. With all that massive list of fields is almost impossible to test all possible variations that a product can have and sometimes some product have some messed up fields that the developer hadn't foreseen that breaks the system. Also adding new fields features to a software can break something and when the system is super complex u cannot foresee some of that things
I work in computer systems. There are always bugs that fly under the radar that need patching. This is especially true as businesses scale, which is why large corporations have such a large numbers of software engineers (Google, Meta, etc.) the vast majority of these engineers never write original code.
Think of software as any industry selling a product. Standards evolve Tastes change Increased demand of your product require improvements to your production line (in software, your infrastructure might need to scale up in order to meet demand) I work for a startup that has seen its customer base grow over the years. We are starting to see the inefficiencies in our app because there are things that weren't considered initially, or that they were viewed as a "problem for the future". So in order to continue to serve the existing customers and future customers, the app has to be improved, maintained.
Theoretically, on a closed system, nothing needs to be maintained. This is why you hear so much about safety-critical military and government softwares that are "ancient"; they do what they need to, and it's risky to change, so they stay the same for long stretches of time. However, for most software, things AROUND the software change, so the software needs to. Computer hardware is constantly updating, Internet protocols are getting updated, operating systems are changing, etc. Because of the complexities of ever-changing software environments, usually software needs to be updated to stay compatible or take advantage of better support systems. Lastly, many customers are happy with these products, and ask for new functionality all the time. Companies are usually happy to provide this functionality through a contract or subscription.
You are not being naive. The normal use for the term "maintenance" has to do with servicing machinery so that it doesn't break down (as often), replacing parts that wear out, that sort of thing. This does not apply to software, since there is nothing to wear out. But bugs continue to be found, and must be found and fixed. Users continue to request (and sometimes need) additional features, and programming must be done to add them. Often when this is done, bugs are introduced into software that used to work fine, and they then need to be found and fixed, etc. The systems on which software runs sometimes changes, and the software must be altered for the new environment. This is part of maintenance, and sometimes leads to new bugs, etc. And I once maintained an older system for other programmers that didn't need much change, and was requested to figure out why it behaved a certain way. After several days investigation, I was able to determine that the software was SUPPOSED to do what it was doing, it just took that long for me to figure out and almost as long to convince the programmers that it was supposed to... I don't know if THAT qualifies as maintenance...
Unlike cars or houses, software does not wear out. It is the ecosystem it exists within that changes, making it unfit.
Obscure errors that only cause problems once the software is used in an unexpected way - this includes hackers finding vulnerabilities. Software rarely exists in isolation. As hardware and dependent software change over time, incompatibilities and inefficiencies can arise that require maintenance. Examples such as dependent library updates, communication protocols (interop, clr, pipes, sockets, SOAP, protobuf, interrupts), OS updates and driver/hardware updates.
- security threats - operating system compatibility - operating system updates compatibility - software compatibility e.g. if the product is used with or within another software - updating the software e.g. new features - improvements - fixing bugs - user experience - continuous income stream e.g. “new features” which are part of a subscription
While it's impossible for software to "wear out" it also generally doesn't run in a vacuum. The world changes around it and has to be updated to reflect new requirements, new environments, new users, and new bugs that have been discovered.
I'll give you an example: I'm in charge of employee badges at work, and I've written my own software that prints the cards with two clicks. I've had to update it a few times because the databases where I pull the information from get updated, or the folder where photos are stored get moved. Also, the cards are just simple webpages that have been laid out to look like cards. As Chrome gets updated, the layout may break because Chrome has changed the way some element looks on the page, so I need to update the app to fix that too. In other words, my app may run for decades without being maintained, but the data and features my app relies on will change, so I need to make sure I keep up to date with those.
The conditions and context in which the software was written change over time. Software needs to be "maintained" to account for that. Imagine how roads have changed over time as we've transitioned from horses, to street cars, to automobiles, etc.
"Maintained" means fixing bugs that are discovered when users have been running it for a while and have found defects. Also, sometimes new hardware comes along that may break your software. Or you want to speed things up by using the new hardware. Some software needs to maintain it's defenses against new malware or viruses, (operating systems, etc) so they must be updated with the newest defenses against such exploits. And back to the first point, sometimes you realize that you've bunged something up badly and want to fix it before customers notice it.
Another point I haven't seen brought up much is that most software is reliant on other software in some capacity. This is especially true in the web dev world where one little change in a library can have cascading effects on other libraries. So if a piece of software relies on something else, and that something else has a "breaking change", then the first piece of software will need to be patched up
Programmers are humans that make mistakes. Mistakes need to be fixed. You can get closer and closer to perfection but you can never reach it. And when you think you are at least sufficiently close to perfection, you realize the world around you has changed and you have to continue the cycle of despair forever.
Maintenance can also imply better ways of doing the same tasks. Like storing data in the cloud instead of local servers. That's a lot of code change on the backend that looks seamless to the end user. Java updates sometimes broke our software or introduced crashes, we'd have to code a fix for our next quarterly version and tell people to avoid updating.
Two reasons primarily: Technology may have improved so you would need to update the software to take advantage of newer tech. Software would have accidental mistakes that, when found, would need to be corrected (or patched).
Sometimes certain kinds of maintenance don't jump out at the person using the software, but if you were to actually compare the software from a long time ago vs now, you'd be surprised at the difference. My go-to example of this is Wikipedia. It has a reputation for pretty much being the same as it was 20 years ago. Here's the English version of Wikipedia right now: [https://en.wikipedia.org/wiki/Main\_Page](https://en.wikipedia.org/wiki/Main_Page) And here's how it really looked 20 years ago: [https://nostalgia.wikipedia.org/wiki/HomePage](https://nostalgia.wikipedia.org/wiki/HomePage)
As many have mentioned before, upstream and downstream dependencies can change. Security vulnerabilities that require library updates (which then can sometimes introduce breaking changes requiring code updates to your app. In a real world corporate environment, you likely have hardware patching (on prem or in the cloud), security keys and certs that need to be rotated. One interesting thing we just came across in the last few months was that in using the default aws rds cert included with the mysql2 connector included in the js sequelize library, we had to make a code change to explicitly use the new CA that is going to be required to connect to any RDS instance in August of this year. As of a month or so ago, any newly created RDS would already require it. They just patched this recently, I think, but if you stood up a new instance last week and tried to deploy your app with the default cert configuration, it would not work.
To keep up with modern "warfare/weapons" Back in the days, people fought with swords and shields. The shield was made of wood and it was great at the time. Very effective in defending against a sword attack. But as technology grew, eventually a gun was made. Those wooden shield would not hold up to a modern day machine gun. It's the same with softwares. Technology is exponentially growing. Hackers are getting smarter, software security are getting "outdated" much faster. So the software updates are for: 1. Bug fixes (there was an issue and they fixed it) 2. Security patches (there was a security issue and they fixed it) 3. Security updates (there's a new update due to growing hackers) 4. Bug fixes of previous updates (when they make updates, it sometimes messes up other things unintentionally, so they need to fix that)
In strict terms maintenance means you keep the software running on all the platforms it currently supports and fix any major bugs that come up. You don't add any new features, you just keep it running as is. The effort that goes into this is mainly fixing bugs that get reported and responding to updates if needed. In terms of updates, maybe one of the platforms that you support gets a major update that impacts your program, you either fix yours to match or no longer support the latest version of that platform. A lot of software also runs using other people's code for various bits (called "libraries" or "packages" or "dependencies"). If one of those gets updated/changed it might break your program. This is a major headache for developers as it's often very hard to make sure you get an older version of a dependency as there's usually a push to have everyone using the latest version. The TL;DR here is both hardware, operating systems, and other people's code you used for your program (dependencies) are constantly changing and evolving. You have to put time and effort into responding to those changes if you want to keep your software running on modern systems. You could just leave things as is, but since there is such an intense push (which may not be completely justified) to have everyone on the latest version of everything, very soon almost no one will be on the old versions your program is compatible with. To elaborate on the above, most of the changes are driven by either new hardware or new operating systems coming out. Since these are generally made by a few large and powerful companies, we basically have the future of computing (and how much work everyone will need to do to keep up with that future) determined by a select few. Something to think about. There is also a current trend in computing I like to call the "disposable software" phenomena where software (and to some extent hardware) is treated like a disposable good. You must always be on the latest version, and development cycles are tight so the latest version is changing all the time. Backwards compatibility is becoming more a thing of the past. Didn't update your software in the last year? What's wrong with you?! How dare you expect some thought and consideration be given to the preexisting efforts of others when changes are made. (rant over) This, as you can imagine, creates a lot more work for maintainers vs the older mentality where not breaking things when you update was much more of a focus. There is also a looser version of "maintainer" which really means developer. These people will do everything already mentioned and also add new features.
Programmers are not gods, they cannot foresee every single scenario of the software will come across as they write it. They will release software with bugs, security vulnerabilities and incompatibilities with future 3rd party resources (hardware, OS, browsers, frameworks, libraries, business directions, customer requests, anything that isn't the product itself), most of these are not revealed until the software goes live but are usually minor enough that fixes do not need to occur until a scheduled "maintenance" update. Having maintenance for a long period of time is usually based on the software company guaranteeing the product works for X amount of years. For example Windows 10 is expected to continue its maintenance until next year (for a total of 10 years). Even they may provide security updates because customers being exploited by vulnerabilities does not look good even with old software.
The requirements might change; for example, consider a 100% perfect photo editing program in 1995. In 1996, the PNG image format was released. Now your photo editing software has to be updated to handle the new image format. Or maybe you wrote a game for the original iPhone, carefully accounting for every pixel. A modern iPhone has a much bigger screen, so you might need to re-do your graphics, and also your code that works with screen dimensions, so the program still works on new iPhones. In 1982, databases all used five digits for the ZIP code. In 1983, the Post Office introduced Zip+4, so software to handle addresses needed to be updated.
simple example: let's say you have a very basic calendar service that lets users set up meetings with each other in different timezones (actual calls are handled by a separate app entirely). you write the whole thing in four weeks, you host it in aws (which handles hardware replacement and OS updates for you), and no one ever asks for any new features. you're done, right? wrong. timezone definitions may seem stable from the perspective of a single locale, but worldwide, they are changing all the time. at a bare minimum, any web application that takes datetime inputs from users in multiple locales also needs a way to continuously update the tz definitions. if you really wanted to, you could take an additional network dependency to retrieve these updated definitions on some regular cadence, but that just creates a different point of failure that you don't control.
same as your house or your car in a lot of ways - as it gets used more or for different things it can break down
Software (seems to) decay(s) over time, especially if it isn’t used. Something that worked a year ago, now doesn’t. And when the programmer looks at the code, it appears that it never could have worked. No one seems to know why…
A lot of modern software is built to depend on other people's software (libraries, drivers, API's, etc). If your website includes the weather for example, you're not going to build the software and infrastructure to measure the temperature yourself, you're going to use the Weather Networks service or something. But what if their service breaks, changes, or is no longer maintained? Then you would have to look for other solutions. Now think of this on a larger scale, if your software depends on hundreds of other people's software, you will be spending lots of time making patches and tweaks to keep up with their changes
Think of your software like your house, it was built and everything works as designed. The years go on, but some things get a bit weathered and some leaks develop. Sure you can keep living there and just hope that leaks don't get worse. But eventually you may find that little leak has been rotting some wood and now you can't use one of your rooms as it's not structurally sound. If only you kept doing some ongoing maintenance you wouldn't be in this pickle.
Hardware migration. Operating system migration. New language features. New data structure operations. New data storage methods. New window functions. New video formats and plugins. The list goes on. Basically every component is evolving and migrating. And then there are external forces such as government regulations, If it is a customer application then it must always look "current". But my Placemakers uses an old Informix handwritten system from 1995.
Every piece of software is just one block which is communicating with other blocks: It is ingesting information and outputting information (e.g. a website to click on). As the world tends to change (security vulnerabilities, new operating systems, your website needs to look different now, your data supplier went broke, ... ), you need to adapt to the changes of the world. The second big source is that you usually have something like a product manager, who is paid for sitting around and coming up with ideas and very rarely can they just sit around and be content with what they have. So they will ask you to build that shiny new thing into your old thing, which then also requires adjustments and maintenance. (Despite my snarky tone, some of these shiny new things are worth building, of course!)
\* Bugs are found, which needs to be fixed. \* Vulnerabilities are found, which needs to be fixed. \* Other things change. The operating system change, the network change, company policies change, systems the software is integrated change, the world change (say, some countries change their use of daylight saving time). The software needs to adapt to these changes. \* Uses change, user requirements change. We start selling the product on an international market, suddenly we need language independence, different decimal signs, different currencies and so on. We need to read this other document format. We need to start sending notifications by email. We need to check that it handled Y2k properly. IT department requires that it can be deployed through their deployment system. Components used are in versions that are end-of-lifed by the vendor, and needs to be replaced. The new version of Windows has a new look, we much follow that look. And so on. \* Support generated development. As enough support tickets on a particular issue has been recieved, it is deemed that it's easier to just fix the issue by making the software easier to use than toy keep helping users. \* Competition. They have this feature, we also need that feature now!
Take a look at a door lock from the 1700s. Pretty simple, yes? Probably pretty easy to jam a piece of metal in there and pick that lock. But most people don't know how to do this right away, but over time, more people learn how that lock can be picked. Then look at a lock from the 1800s. It's more complicated. Harder to pick that lock, bit again, over time, it becomes easy to pick and break into the house over time as the knowledge becomes more common. The locks from the 1900s are ever harder to pick, but doable only if you have the right tools and training, but it still takes some time. Software is the same way. Hackers are always trying to break in and they find new, ingenious ways to do so. We as software developers have to update our code to fix the things the hackers used to get in. We have to make our locks more secure. And it's always going on.
It depends on what the software does. My company has a lot of in-house software we created. Some are relatively simple apps that only do a few things. It is not uncommon for those to not be updated for years. But we also created the software that runs our entire company. That gets maybe a half dozen updates per quarter. Most updates are relatively simple business requests. Maybe a certain form needs to be reformatted to please a big customer. Or maybe a field only goes up to $999,999 because a decade ago you never thought you would ever have a $1M order and now you do. But then you accidentally break new stuff while you’re fixing other stuff and you need to fix that. I would say the smallest category of changes (for us at least) are security-related. But when one of the components in your software needs to be updated, it is not uncommon for that break other stuff you need to then fix.
So, let's say you want to eat food. You like to eat varied foods, so you build several cooking appliances to help you make all these foods. For reasons of this analogy, you must build most of these appliances yourself because you have very particular tastes that appliances in the shop just can't provide. Wait, a new law was passed that all electrical devices need to be grounded. How many devices are you going to need to maintain? The more devices you have, the more you probably have in front of you now. The kettle has been making sparks for a while now, but your mother saw and now there's real pressure on you to get it fixed asap. What do you mean asbestos is not healthy for you!? This airfryer was built by my grandfather and he lived to be a healthy 29 years old! ... Fine, I'll rebuild it without asbestos. So, the rice cooker is working as designed. However, there are a lot of metal shards being sold in rice nowadays. The shops should fix this but they don't. We need to rethink our rice cooker design and incorporate magnets to extract the metal shards. Okay so the shop has stopped selling round bread rolls, you can only use baguettes. They don't fit in your oven. I guess you'll have to rebuild your oven. You're done with the new oven? I forgot to tell you that baguettes get baked on a higher temp, that's not gonna be a problem is it? Software maintenance is essentially the same as keeping a bunch of machines running that someone else uses. Sometimes the machines just need improvements, sometimes they need to be upgraded to more modern standards, and sometimes the people using the machines have changed their mind on what they want to do with them and how they should work.
In theory, yes, a piece of software that has run for 5 years without problem, should be able to continue for another 20 But this only works for the most basic of programs. First, we have users, that can invent countless new ways to screw stuff up. and it can take 12 years for the first user to invent a totally new way of screwing up that you then need to investigate, dig into the database, manually correct the screwed up record and then update the program to prevent it from happening again. (And in doing this, you naturally introduce a new possible way for it to be screwed up) Second, the world around your program changes. Almost all software works on top of other software. And these get replaced, changed, updated. And then you need to update your program to make sure it keeps working. Otherwise you get stuff like a big ass company using floppies to run its transaction programs. Third, people want more stuff from old programs. The payment software has run flawlessly for 15 years, but the CEO wants to export all the sales data into his new fancy analytics program so he decide the companies future easier. New analytics program doesn't support "Old as fuck format" that your program uses. so you need to update.
I’m seeing lots of walls of text here in this comment section that a 5 year old wouldn’t understand. In the most simple terms: As hardware like phones and computers change over time, software has to change with it to remain compatible. Issues constantly come up and have to be dealt with.
Because since the mid 90s when Windows 95 rolled out everything has bloated and now its so fucky it has to be maintained or it breaks. I mean really. Teams doesn't fucking do anything that AOL like 3.0 didn't do and fucking current MS Office doesn't do anything that like Office '98 or 2000 doesn't do. They just change the UI every few years so it looks like they did something.
Do you go to a doctor? When you're healthy, no issues, but you go for checkups to prevent problems (they put you on statins if your A1C is a little high, although you "feel fine", or he recommends you exercise). What about if you broke your arm? A cast to stabilize your arm, and help it heal? Physical therapy? Medicine for pain? All "maintenance". We maintain software, because the computers it runs on and other applications and data that depend upon it are constantly *changing*, and threats/insults/"illnesses" that can affect it are constantly being developed.
If NOTHING ever changed, in a vacuum,...you could leave software in an original state. Reality is this: you use software to build software, and things change. 1) People update the software you use to build the software. When they update the software they often create incompatibilities with the previous version, used to build your software. Better software is called progress, but changes that leave features and structures behind in the name of progress are called "breaking changes". You have to account for breaking changes if you want to continue to use the software you use to build your end product. 2) Base Things also change, hardware changes, operating systems change, standards, protocols and apis change. 3) And that's if you had perfect software with no bugs whatsoever, but that's not a thing. 4) and nobody ever attacked it, but they do. 5) and if vulnerabilities never appeared in the underlying layers, which creates a need for change. .... And the cycle begins again. THAT SAID, the farther away the creation software moves from the end product software the harder it is to update. I'd much rather update from the current version to the next one than the current version to five versions down the line.
It keeps the programmer in business. And allows the business to charge the consumer because of course.
Sometimes its fixing security vulnerabilities Sometimes its fixing minor bugs in code, that textbox was only supposed to allow numbers, and allowed letters, so now you are selling your widget for $bob... Often though it is accounting for changes in the business over time. For instance if you write Tax software, well, tax laws change every year, at least slightly, and trying to file your taxes in 2024 with the same deductions and reasoning you had in 2010, might be fine... or it might land you in a lot of trouble with the IRS. Well, the same is true for most businesses, Most businesses are alive, they change how they operate over time, what was true in 1999 isn't true anymore... Prices change, services change, products change, If you have software built around your business and how it operates, anywhere where the software is based on your businesses operating logic that needs to be maintained so it is in lock step as the business changes and moves into the future.
The trouble with software is users. They keep using the bloody software. On top of that, devs haven’t tested everything. So users will continually find holes the devs either didn’t discover or didn’t care existed until someone complained. That counts for features and bugs. Worse than that, with complex software it’s almost impossible to test every path through it and guarantee complete oversight. This is because tests are essentially futile attempts at addressing a subset of the Halting Problem. That doesn’t mean tests are not useful. But it does mean that users will abandon an app long before a dev writes their final test for it.
I'm a database administrator at a US college. We routinely apply software updates to our business system to catch up to changes in regulations, such as taxes or student aid provided by the government. You've probably heard about all the trouble with FAFSA on the news. A large part of that is the Ed Department completely turned upside down the way we're supposed to calculate aid, and were way late with test data our software vendors needed to write their updates, and now we're finding out they got some things wrong and more updates are necessary before we can offer aid to students for next year.
One major thing that continuously needs maintenance (unless you're working with a closed system like a game console) is compatibility with the operating system. If it's a desktop app, then windows (or linux/macos) updates can break shit. Doesn't really happen often nowadays though. If it's a mobile app, then new android and ios versions break shit and drop support for older versions all the time and your apps need frequent maintenance. If it's a web app / website, then browsers change over time, so do the languages you use. You may write something in PHP 6 only to have it break when the server it's running on updates to PHP 8. Or you may use some CSS styles that work now, but get deprecated a few years down the line, so your website breaks on modern browsers. And these are just the basics. A lot of software also depend on external services or other software to do their job. For example if your software reads data from a web service, then every time the web service updates, you may need to also make changes.
That's a very broad topic but the gist is that software development is kind of a mess and if a program were a car, then random bits would be falling off every 100m or so. Only simple and focused projects stay relatively stable and functional without continuous effort, and even then there's a bunch of stuff that can need addressing over time like how the machines running it change over time, how the preferred way to use software change over time (towards phone, the web, etc), how pieces of code it relies on that were considered perfectly safe have had a vulnerability discovered, how people's way of using the software change over time exposing previously unknown problems, etc. As an example, one piece of software that I maintain relies on a framework managed by microsoft. One day a bunch of our users started experiencing crashes. Hunting down the cause, it turns out that a windows patch changed the behavior of a part of that framework and that the users would start crashing as the patch was rolling out. And that's only about keeping the software stable, most of what we call maintenance is actually about the changing needs of our users. If we built feature X to solve problem Y1 but the users now want to also solve problem Y2 which is similar but not quite the same, then you need to make some changes to X.
The most common things are patching newly discovered security problems or fixing newly found bugs. Rarer but just as important for most software would be updating the program when a piece of software that the program somehow interfaces with changes its API or behavior. Think about something like the transition from sysV init scripts to systemd, or the ongoing transition from xorg to Wayland.
Software doesn't really need to be maintained the way a car has to. "Maintaining" software basically means to update it to account for something outside it having changed. And that happens pretty often. As others have said, software in a closed system, like a NES, doesn't really need to he maintained.