4

I'm a hobbyist programmer, so no professional experience.

People here often talk about doing maintenance of software at work. The author of this question talks about doing 90% maintenance and 10% development at his job.

My question is: what is 'software maintenance' anyway?

Is it mainly about fixing bugs? If so, does that mean that people spend most of their time at work fixing bugs?

Or does 'maintenance' include other things, other than bug fixing?

Community
  • 1
Aviv Cohn
  • 21,190
  • 31
  • 118
  • 178

2 Answers2

9
  • Fixing bugs is definitely a big part
  • Small modifications to existing features: add a field here, change the dialog layout there, remove some outdated functionality there... The difference between maintenance and development is fluid here.
  • changes can even be required by new laws!
  • Improve performance
  • Make the system work in a new environment (because the old one is not available anymore or has had its own bugfixes or new features):
    • new hardware
    • new version of the operating system
    • new version of the programming language / runtime
    • new version of libraries you're using
    • changes in other systems that your system communicates with

Some concrete examples that I have personally worked on:

  • When Facebook switched to local currency payments in mid 2013, all Facebook apps that took user payments had to completely rework their payment logic (the new system works fundamentally different on many levels) within 90 days.
  • If you take direct debit payments in a SEPA country, then in early 2014 you had to switch account numbers to the IBAN scheme (from the form where users enter their data through to where your backend communicates with the payment provider), and if you take recurring payments you had to implement email notifications.
Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
  • Thanks for the helpful answer :) You pointed out 4 things that make up maintenance: bug fixing, small modifications, performance improvement, and adapting the system to a new environment or library. Could you try to point out which of these takes the largest portion of the time spent on maintenance? – Aviv Cohn May 24 '14 at 18:10
  • 1
    @Prog: that is different for every app, but for large applications adapting to a changing environment is usually the biggest factor (because it often requires big changes and large apps have a larger environment). Bugfixing is probably in the second place (first for smaller or self-contained apps). – Michael Borgwardt May 24 '14 at 20:05
  • 1
    @Prog: this answer describes correctly how the term "software maintenance" should IMHO be used. But many people also use it for "adding new features to a legacy system". I guess thats because when your existing system is big enough, after spending one hour for adding a new feature, people often need several hours of maintenance to bring the system again into a stable state. So when you read the term "maintenance", different people may have a different notion of what that means exactly. – Doc Brown May 24 '14 at 20:18
  • 1
    @DocBrown: +1 The software suite I generally work on gets new features added all the time. I would hardly call the work I do maintenance. Maintenance is at most 20% of my work on this system. Yet many people would call it maintenance just because we are beyond version 1.0. And I also do "hate" the term "legacy system". I learned it to refer to systems that need replacing or wrapping, yet now often hear it used for any system that is beyond version 1.0. There is nothing legacy about a software suite in its umpteenth version, when that suite is actively developed. – Marjan Venema May 25 '14 at 10:07
2

Idea of "software maintenance" comes from thinking that software can be managed in same ways as any engineering project. Each such project has a lifecycle:

  • Requirements analysis
  • Design / Planning
  • Construction / Implementation
  • Usage / Maintenance

This means, after the project is finished, some effort and resources are necessary to keep it in fully working conditions. But in all cases, the amount of resources needed for maintenance is small compared to actual implementation. Imagine a big building or complex machine. Yeah, you might want to repaint it or replace some parts, but generally speaking it will remain same for all of its operational lifetime.

So if you assume that software too is an engineering product, then it also has a maintenance phase. The problem is, the assumption that software is same as any engineering project has been confronted many times already. One of the issues related to "maintenance" is that software is so "soft" that it can change drastically even after it's implementation phase officially ends. That is the reason why some people consider "maintenance" to be majority of the effort. Because even though on paper the software is "finished" it is so easy to change it that it will be changed.

This is why most modern software development methodologies don't really have such engineering structure and assume that software will never be "finished" and that it can change drastically at any point in it's lifetime. Even after many years in production.

Euphoric
  • 36,735
  • 6
  • 78
  • 110