Software maintenance has multiple distinct forms: 1. Perfect software that doesn't run in a vacuum. Assume the software has no "bugs". It still operates within

Software maintenance has multiple distinct forms: 1. Perfect software that doesn't run in a vacuum. Assume the software has no "bugs". It still operates within limits, and within an imperfect world. The hardware fails, it gets upgraded and is no longer compatible with the original software, the disks fill up, invisible particles shooting through the universe flip bits. All sorts of things outside the control of the application will cause the application to not function as intended. And as such, maintenance will be needed. 2. Imperfect software run by imperfect people. Even without any of the above problems, users will input the wrong data that the program didn't expect and cause an error. Sure, you could just assume that "software development never ends" (assuming that you will just find new bugs constantly and need to fix them constantly). But you don't have to fix a bug if an acceptable mitigation exists. People who still run Windows 98 or XP can't fix bugs, but they do work around them. And so maintenance can take the form of performing tasks which aren't changing the software, but are tasks that make it continue to function. 3. Actually shipping updates to the code to fix bugs. This isn't strictly necessary. There are many bug-riddled software systems that have been going for 40 years without patches (for the most part). But in the modern era, we have so gotten used to the website model of daily updating a piece of software, that this is what we assume 'software maintenance' means. Once you write a piece of code, you might continue to maintain it using #3, but even if you don't, you will absolutely have to perform #1 and #2, if you want it to keep working. If you are very lucky, and the system is "on" but doesn't actually do anything, you can get away with not doing any maintenance. But the more you use it, the faster it needs maintenance.