I was going to name this article “Maturity model for maintenance programming”, but every time I read that title, I cringed. Maintenance programming is not much fun. It sounds a bit like “prison guard” or “mortician”, or some other unpleasant profession.
It is a tough job, but someone has to do it. More than that, the job needs to be done well. Imagine the results from a prison guard or mortician who is a slacker. You know the results would be unpleasant and people would be pretty unhappy with you. It is serious work and therefore, it needs to be done by someone with “guts”. If you have the guts to do it, then let me offer you my thanks in advance.
When you take-over a project from someone else (another person, or another team), there is a bunch of work to do. You will quickly find how the project went. It probably went like this: At first, your predecessors meant well. They started with some great plans and expectations. Everybody was optimistic and striving for perfection. As the project progressed, the roadblocks got bigger and the team eventually became weary. The closer the project got to the end of the timeline, the more all-of-that-talk about “the right way” tended to fall apart as the project got squeezed by a timeline, a budget and the remaining feature-set (and bugs). Something had to give. People made compromises and got things done. It was good-enough. Now that the project has been handed over to you, your job will be to find all of the sub-par stuff and create a scope-of-work to fix it.
The good news is that, once it is handed to you, the focus on timeline seems to go-away and the focus turns to “reliability”. Which really means [fix the bugs immediately]. Of course, what they really want is a bug-free system, but the term is misleading, because your predecessors will claim that they delivered a bug-free system and there is not much to do.
Removing “the suck”
There are several layers of improvement/maturity that you can take the project through. Each tier makes the system easier to maintain. However, each one also takes increasing discipline, planning, skill and effort to get the system to progress to the next level.
Here are the levels of maturity:
- Released – The project runs and has cleared testing. Hurray! Ship it!
At this point, there are no expectations about maintainability. Up-to-now, the goal has (most likely) been to complete the project by a certain date, with a list of features-completed and passing some reasonable level of testing. If the authors were not required to maintain the code, there would have been no incentives for making the system maintainable.
- Customer Assessment – There are way-more customers than there were testers. The customers (end-users) are going to be more creative than your testers. They are a million monkeys sitting at keyboards and they will give you some Shakespeare eventually. And by “Shakespeare”, I mean “bugs that you never would have dreamt-of”. When those bugs arrive they will be waves crashing on your embankment and your level of resourcefulness will be the key to resolving the problems quickly.
- Stabilizing – The bug waves typically come in a pattern: 2-2-2-6. 2 days till the first wave, then 2 weeks later, then 2 months later, and it mostly subsides in 6 months. You will need to deploy your fixes between these waves of complaints. As you stabilize the app, you would expect the intensity of the complaints would gradually reduce. However, that doesn’t seem to actually happen. The complaints just become less frequent, after a while.
- Supportability – After 2 months, you will start to think about how much time (too much) you are spending on monitoring your app, or wading through code or data, to find problems. At this point, you will start to think of utilities or features in your program, which would make it easier to support. These productivity tools will give a fairly nice ROI. They will make your support-efforts move quicker and more-decisively.
- Performance – After you have several waves of bug fixes and updates, eventually some joker is going to complain that your site is slow. It wasn’t this slow in test (because you didn’t have any data). At this point, you need to do a performance study and optimize the app and database. Expect another of these in 18 months.
- Feature enhancement – After the bugs are (mostly) resolved, people will start chattering about how some of the features are not as good as they’d hoped, or it would be better if… So, there will be enhancements. This means new development. Which means you will have to switch gears back to requirement gathering and scope containment. How soon can the users get this new stuff? No, that is too long. Get it done sooner!
Not every project goes this smoothly or follows this timeline. This is the path a project is supposed to take. Of course there are some variances, based on project size, team size, budget, etc. However, if your project does not climb these levels, it is usually because your leaders are not aware of the natural progression.
It helps to know what to expect, so you can measure yourself against reasonable expectations. Also, if someone has unreasonable expectations, it is nice to have a nice/effective way of suggesting something more reasonable.
So plan your lifecycles, set expectations and stay l33t.