Attempting to Define Maintenance


I've had several discussions about maintenance in the past few days. I'm beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem.

So what happens if there's a requirements problem that led to a design problem that led to a larger (greater than a couple of days worth of work) development problem? To me, that's a short project. Once the problem is larger than just coding errors, it's not maintenance, in the sense that I think about it. If you have to rewrite requirements or fix the design or involve more than just the one or two authors, it's bigger than “maintenance”. And once it's a small project, I can manage it with all the other small projects that are part of a release.

This means that when I work on projects, I see the work differently than others seem to. Because I believe everyone has to fix the problems they created, and because I see maintenance as just fixing those problems, I don't have a problem with maintenance. I do have a problem with scope creep, but not in the sense of new requirements. I have a problem with trying to finish the work the project staff said was already done but isn't.

That's why I ask people to plan inch-pebbles, why I use milestone criteria, why I ask developers to implement by slice instead of by architecture, why I request that technical staff completely finish one thing before they go on to another. A by-product is that I don't normally have to deal with maintenance, unless I'm coming into a project after it's already started.

What's your definition of maintenance?

5 Replies to “Attempting to Define Maintenance”

  1. The company i work for defines maintenace = buf fixes + enhancements.
    If enhancement does not involve a small watefall iteration, then the above defintion is ok with me. But i have unsuccessfully tried to say that maintenance is like “maintaining ur car”. You keep making fixes based on feedback (in IT its our customer). But the moment I got into enhancments, I sufferred because they were treated as another “kind of bug fix”. I also tried to put forth unsucessfully that “adding an accessory to a car (enhancement)” is a diffeerent activity , not maintenance. However couldnt name it.
    Ur term “small Project” is the right word I think. I will try this term next time I am discussing with my ‘take this timeline’ mgrs 🙂 and see what happens.

  2. I think we get confused when we try to use a single term to try to cover multiple dimensions. In this case there’s what needs to be done, and there’s how big a job it is to do it. People are generally using “maintenance” to cover certain types of what (e.g. bug fixes) and certain scales of size (e.g. small jobs), but without being clear as to just where the boundaries are.
    There are several types of “what”. There’s making the system do what it was always supposed to do (defect fixing). There’s making the system do stuff that wasn’t originally envisaged (enhancements). There’s stuff that needs to be done to keep the system running normally (e.g. backups).
    Defect fixing can sometimes be a big job. (e.g. I’ve seen cases where people pretty well had to rewrite the system from the ground up to achieve performance goals.)
    So what I try to do is draw a map and say “Maintenance is all enhancements beneath a certain size, and all defect fixes beneath a (possibly different) size. Enhancements or defect fixes bigger than these limits are new projects. (We may need to negotiate different pricing for defect fix projects versus enhancement projects.) And admin is the ongoing process required to keep the system running.”

  3. At my company we tend to group each of these actions by whether or not they are for a single customer or for the product.
    This is when you are doing work you expect to do on the system.
    (e.g. reboot servers once a week or build a pcinstall for a customer.) this our things that are knowable in advance, for example based on the current design we know there will be some HTML for each new customer, but it is bounded in scope and time, anything beyond a threshold is new development for that customer. Maintenance tends to be done by system admin and data admin. Although the custom HTML is done by a junior engineer.
    Defect Fixing:
    This is when something is working wrong. This is different than the testing q/a stage of development.
    Comes in two flavors, new and enhancement. we do them the same way, but we have to bill to seperate charge numbers for other reasons. defects caught during development q/a is part of development.

  4. As all who have commented here before have alluded, there are any number of ways to break this down.
    I think that the primary difference in some the expressed opinions derives from the culture of the organization that sponsors the product. Some organizations are very focused on project alignment, and in this case maintenance becomes just about any work that is not project oriented.
    Other organizations are more product focused, and therefore, maintenance can be thought of as tactical enhancements (performance, useability, planned extensions to existing features) that are done without changing the direction focus of the product. Things that might be included in a “point” release might be considered maintenance. These releases may contain these small enhancements in addition to some bugfixes. Whereas development might be thought of as Strategic enhancements (extending to software to new platforms, building new feature sets, or reaching out to new user communities, extending the application architecture) these would be obviously considered as development. The difference in my thought process is that maintenance is limited by the boundaries of the current software design and development extends the boundaries of the software design.
    In the organization that I had been leading up until very recently, we typically had both cycles running concurrently. The maintenance cycles typically run very short 30-45 day delivery cycles, and can deliver boatloads of good stuff to users (scores brownie points, buys credibility, builds goodwill) while the longer running development cycles may include prototype and beta releases and require much more intensive user involvement, and sponsorship. Still, I found that if we defined very short term 45-60 day interim delivery cycles, for these, it is much easier to do the branch and trunk development. It is easier to bring the trunk code changes (maintenance) up to the branch (development) more frequently, than less.
    For those of you who say that this type of work can only be done in some ultra-progressive start-up company with loose software development policies. Those of us who are committed to delivering product to our users have often reverse engineered the policies that on the surface seem to require big top down waterfall like processes, and found ways to become agile by getting closer to our user community.
    Try this out. My business analysts take support calls and often use that user contact context to validate related requirements for upcoming releases. They tend know users on first name basis (even though our portfoli management and trading system has hundreds of users). They know which users focus on key features of the software and can quickly pull together an impromptu focus group, or poll their constituents to validate our understanding of the problem domain.
    This work is done, before, during and after the design phase, to ensure that our design meets the needs of the c

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.