The idea of software maintenance sounds absurd. Why do you have to maintain software? Do the bits try to sneak off the disk so that someone has to put them back?
Software doesn’t change, but the world changes out from under it.
- People discover bugs. This does not change the software but rather our knowledge of the software.
- As people use the software, they get new ideas regarding how they want to use it.
- The human environment around the software changes. Organizational priorities change. Laws change. Project sponsors and users turn over.
- The technological environment of the software changes. Operating systems, networks, and hardware all change.
- New possibilities emerge and make us less content with old possibilities.
People often perceive these changes as changes to the software, like someone standing on a dock, eyes fixed on a ship, who feels the dock is moving. We speak of software as if it were some mechanical think that physically wears out. Of course it isn’t, but the effect may be the same.
11 thoughts on “Why does software have to be maintained?”
At the same time, while requirements may change, and that is basically what you’re talking about, change still costs money. So long as there is a $ in front of $change, then who cares how often it is needed. Once your remove that, though, that is when, in my experience, change becomes a real burden and goes from the “should” to the “shouldn’t”.
Christopher: And that’s a real problem for in-house software development where no money changes hands. As long as your time is perceived as free, people will have infinite demands. But if you can attach the slightest cost — say in time, if you can’t charge money — things become more realistic. I’ve had people tell me a project was absolutely critical, until I asked them to lift a finger to help. Then they decided it wasn’t so important after all.
Software maintenance necessitates software maintenance.
If I want to do anything with digital video, I’m probably using ffmpeg under the hood. Even if I get the program completely right on the first try, ffmpeg is going to change, and my program will have to change with it. This is basically what you are saying in your ‘technological environment’ point, but I wanted to explicate the fact that the reason the technological environment changes is because of the same maintenance it then forces in the software around it.
The best book that I’ve read dealing with writing software for money is called Facts and Fallacies of Software Engineering, by Robert Glass.
He refers to one of the “facts” as the 60/60 rule: 60% of software’s cost is maintenance, and 60% of maintenance is adding new features.
But he never mentions that “maintenance” is completely the wrong word for it – great insight!
Also, sometimes people get new ideas about how to implement algorithms, or new ideas about which algorithms to use, neither of which are bug-fixes in that the existing methods were, at worst, suboptimal (by some metric), but not incorrect. (This might be subsumed under ‘new possibilities’ but I think it’s interesting enough to merit its own entry, because it motivates encapsulation to a certain extent.)
Examples would be replacing an array with a bit-field or choosing a different sorting algorithm.
The ship analogy is a good one. As with boats at sea, the appropriate way to maintain software is “not too many planks at once”
Another important point is that in a system that includes human, hardware and software components, change required of the wider system migrates to the software component for the simple reason that it can, in the sense that the software is the component that is most easily changed.
Couldn’t agree more. If you have made such an ecosystem that most apps on your OS is well maintained, then rapid platform advancing is of the most importance and backward-compatibility is nonsense. That’s why a platform emphasis backward-compatibility fade.
What about the practice of releasing software with known bugs that will be fixed in future maintenance releases?
The first thing that came to my mind was data maintenance. Several times I have been presented with old data on punchcards or an old teletype printout. Luckily there was just enough contextual information included which made it possible with a lot of work to make some of the data useful. I don’t have the same optimism when considering old tapes or floppy disks. Although in the case of electromagnetic media there is a true maintenance consideration, as they can degrade, I’d also be worried that it would be hard to source a reader. Although old punch card readers are hard to find (I tried it) punch cards can at least be optically scanned and the images interpreted.
Another issue which has been touched on but which deserves more mention is the maintenance cost related to figuring out what someone else’s old software is supposed to do and actually does. Related is the question of why things are done the way they are. Those costs can easily be high enough to justify throwing out the old software and starting from scratch when maintenance is required.
These two issues both relate to disappearing contextual information, although some of that information is embodied in devices. The contextual information is particularly difficult to document since it is normally so pervasive it is effectively invisible, like air. Even when it is straightforward to document, it seems silly to do so because it is so common, and tedious because it is not typically interesting, exciting, or unusual.
along with the usual items regarding bug-fixing (planned and unplanned) another question i often ask my clients is “why do you need to change your code _so_ _often_?” IOW, there is most likely opportunity to reduce the number of times changes in the domain model (data and behavior) will require changes in various parts of the system.
usually this means shipping both data and behavior information with each message/repsonse. in that way, client applications can recognize behaviors in the message and act using that data. this can reduce “hard-coding” domain-specific behavior into the client apps.
to date, the two most common ways to do this are 1) mobile code [i.e. ship script in responses] and 2) hypermedia controls [i.e. HTML, Atom, etc.].
in my experience, not enough of this type of thinking/implementation is done; esp. at the enterprise level.