Friday, January 22, 2010

What is software "maintenance" anyways?

Something that has been beginning to annoy me lately is the term "software maintenance".  Why?  Because the metaphor of maintenance is meaningless to a technical person and implies too much meaning, that doesn't fit software, to business people.  What are these oh-so-bad implications?  Ever hear any of these?
- "Maintenance projects can't use, or are not a good fit for Agile."
- "[Jane/Joe Programmer] is a maintenance developer."
- "80% of a (software) project's costs are from maintenance."
- "Maintenance funding is a corporate expense." (vs. a capital investment)
- "[Project X] is in its maintenance phase."

Some of these sound important, like project funding or costs, and others sounds absolutely ridiculous.

First, let me define maintenance using my favorite definition:
"The work needed to keep an asset in a condition that enables it to retain its original value or service potential.  Maintenance does not extend an asset's normal expected life." -- [Here is the original source I tweaked it to be a bit more specific.]

Next, let's take a look at the kind of tasks one might see on a so-called maintenance project.
1. Bug fixes
2. Performance tuning
3. Infrastructure/Technology upgrades
4. Refactoring (improving code without changing its function)
5. Enhancements and changes
6. Adding whole new features

After reviewing the list above, a few things jump out at me:
First, only items 1-3 fit squarely into the definition of maintenance given above.
Second, for every maintenance project I've ever been on, 60%-80% of my time was spent on items 4-6.
(So why do we say that 80% of a project's costs are in maintenance when so much "maintenance" activity is not even really maintaining the product?!)
Third, (and most importantly) all the items on the list are things I do on new development projects!

My conclusion?

It's all just software development!  I know this isn't exactly a great revelation to techies or anything, but it is important that this is realized, especially by managers and business folks.  "It's all just software development" is the technical equivalent to "he's just not that into you".  This realization frees the mind from the flawed metaphor of maintenance and all the wrong preconceived notions it drags along with it.  Of course Agile principles sill apply; its software development! So-and-so is not a maintenance developer.  So-and-so is just a developer!  Software doesn't have a maintenance phase that is costly.  There is simply a choice of whether to continue to add value to the business by enhancing the software or not.

A few caveats before I get flamed.
Yes, continually enhancing code can become very costly if corners are cut, test harnesses are not in place, and technical debt continues to pile up.  Usually at some point, a critical mass is hit and, if the system is needing to be enhanced, a rewrite will be required.  This brings on problems of its own that could (and maybe someday will) warrant its own blog post.
Yes, there is such a thing as maintenance for software, but I will assert that it is only items 1-3 in the list above.  Those are the only items that simply maintain the software in its original intended state, providing its original intended value to the business.

So what is missing?  If its "all just software", why do I like some projects and not others?  What is the key differentiator?

Well, some projects I don't like because I inherited them and they were poorly designed or poorly written or dont have any tests, or seems like some amorphous blob attempting to suck out my soul.  But you know what though, while these can be sluggish to wade through, there is also some sense of accomplishment in getting to make it all better!  It is a different kind of joy than getting to design and implement a brand-spankin-new solution, but both are programming and both can be enjoyed for different reasons. So I dont really believe any of those negative aspects of Legacy Code are the key differentiator.

I think the real issue is something I have started calling the Development/Support Dichotomy, or DSD for short.  DSD occurs when some piece of a software project is being used in production.  The problem this causes is when something breaks hard and business stops or is severely impacted and the team or individual working on the project must stop planned work and react to unplanned work.

My next article will be more detail on DSD as well as ways to solve it.  For now, can we all agree that true software maintenance is pretty narrowly defined, and not actually that bad?  Could we further agree that, most of the time, what we are asked to do under the term "maintenance" is actually some other kind of on going software operations? (or even better, continued investment?)  Great!  Now let's get the business and management types thinking and speaking that way!

1 comment:

  1. Jeff Atwood compiled some great thoughts on software maintenance a while back.

    In particular I like the idea that all programming is maintenance programming, with the exception of the first 10 minutes you're writing the code.

    To put it pithily:
    "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live."

    ReplyDelete