How Do You Measure Maintenance
How Do You Measure MaintenanceCan Maintenance be quantified?
What exactly is it that you want to quantify about maintenance?
Right. I think we've got this backwards: We shouldn't be asking about the system and the programmers, we should be asking about the users:
How You Measure Maintenance
Put the software into production immediately. Then everything is maintenance. Done measuring. --RonJeffries
The question was how to measure, not how to be done measuring. If we put the software into production immediately, we might get an excellent opportunity to count irate customer calls, which is a kind of measurement. Not quite done measuring. On the other hand, we might be done developing software. -- WaldenMathews
It's the same question as "what is writing code and what is refactoring?" There is a way to do it that makes the question moot. For the coding vs. refactoring question, the way to do it is to write a test that fails, then refactor until the test passes. Then there is no separate "writing code" step. For development vs. maintenance, the way to do it is to deliver usable functionality to the customer in the first iteration. Everything after that is maintenance. Yes, making the question moot is cheating (for some definition of cheating). However, you may find that winning generals usually cheat.
No, I'm sorry, I don't hear the same question there at all. One is about measuring something; the other is about clever definitions. I don't know about "cheating", but I don't think it's very helpful to change every question into the one you want to answer.
I think of "maintenance" as keeping working things working. A software business may have a legitimate reason to separate maintenance expense from other expenses. Maintenance work is often thought of as piecemeal, and the association applied in reverse ("If the work seems piecemeal, then it must be maintenance.") In evolutionary development models, that definition doesn't help much. Instead, I have always reported work on old functionality as "maintenance" and work on new functionality, no matter how small, "new work". But in practice, it's never quite that clear cut.
Still, I'm not convinced the real question of this page is "How do you decide if it's maintenance or something else?". It seems (at the top) broader than that, including things like the cost of deferred maintenance. I wonder, can we have a page about measurement without it turning into an anti-measurement campaign? Is measurement "icky" or something? I'd like to know, because I seem to do it all the time when I'm building something or trying to get better at building something. -- WaldenMathews
One way I've seen depends on having a DefectTracking system in place. But do not simply count the number of defects that can are marked closed. Track the number of defects that stay unfixed for a long time -- say three weeks, or whatever works for your shop. This helps spot the reported defects that hide more complex groups of faults, and identifies the responsible persons who may not be as effective as they could be.
Relative to what a 'defect' is: there's the idea that a single incident as entered in the tracking system may in fact map to just one fault or a complex set of fault, as discussed in DefectTracking. I'm not saying use the defect report in the tracking system as the only unit, but as a starting point for measuring the effectiveness of maintenance.
-- StevenNewton
I don't find "defect" is an effective unit of measure. The variation in what is categorized as a defect varies from simple typos in a user screen to complex threading and timing issues. There is a several order of magnitude difference in the complexity of different types of defects.
-- WayneMack
I would suggest just using the number of user help desk calls or complaints as a measure. This would reflect the usability of the software. It also skips the arguments over whether something is a bug or a new feature request. The only problem with this measure is that users tend to get tired of calling in complaints; the number of help desk calls will decrease even with no software changes.
-- WayneMack
I've always had the theory that some software companies I've worked for have an unwritten policy that they don't want the software quality to be too high. The reality is that annual maintenance revenue is too large a piece of the pie, and if your customers are paying yearly for no perceived benefit, then they'll stop paying and just keep using the version they have. In fact, I know that in several cases the companies I've worked for have stopped paying annual support charges for stable, workhorse software that we continue to use-- in one case this was our source control system (and it wasn't even that good!)
I wouldn't be surprised if you ask a customer which of their software vendors are the best, they'll pick a company with a reasonable amount of defaults, that are fixed in a responsive manner, rather than one that works quietly in the background never causing any trouble.
EditText of this page
(last edited April 3, 2003)
or FindPage with title or text search