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?Tags: inch-pebble, iterative planning