Maintenance revisited – part 1

Maintenance is a tricky subject, and before I continue, I would like to distinguish between applications that are truly in maintenance mode and the ones on which there is still ongoing development. Obviously, if the application is not “moving” any more, the best you can do is to outsource complete thing and let other guys being busy – providing you have automation tests in place, trained people and good maintenance contract.
Bigger dilemma comes when application gets first time deployed in the field and when bugs come back to the team (which is not necessarily a bad sign per se – it can be as well indication that people start using your application). How much of problems you have in the application depends on the quality, which depends on good design,  early testing and having right people to do refactoring.  There are plenty of books about “broken windows” and “Next gen” phenomena, when early releases are such a mess that you have to do it one more time – so you keep the old system alive and try to catch-up by delivering a new product. I hope you are not there, and if yes, I suggest you skip this blog and wish you good luck – you may as well read some other books first (“Clean Code” , “How to fight depression” or something similar).
In this blog post I will be talking about finding the right balance between making new things and solving past problems, keeping people motivated to work both on “new cool stuff” and bug fixes, and managing customer expectations. Of course if you are a lucky guy and you develop applications on the server side in the cloud, many of the issues that will be discussed here are less of a problem (deployment, bug fixes, merging issues etc).
Let’s start with people. As we all know, it is always much more fun to develop new features than to fix bugs. Creative people often think that the only part of creativity is to work on new things and if they get assigned to fix bugs, they might see this as a sign that you don’t appreciate their work. In my opinion, this is a primary reason why there is a common practice that novice on the floor gets to learn application by bug fixing. I think that this idea came first from guys that just hate bug fixing, and like in the army, made new guys to do some dirty stuff first, before they are allowed to work on some more rewarding activities. I find it so wrong on different levels. In some other places, you may see the opposite, where senior developers who are overwhelmed by doing bug fixes, get demotivated and finally run away from the project or the company. So, be careful how you address these issues, since mastering maintenance work is what makes or brakes your business in long run.
First, let me go back to creativity. I have all my life played handball and learned to respect sport stars. What people don’t see watching a game on TV is how much hard work and discipline is required to master any activity. Therefore, you need to establish a culture in which the bug fixing is part of normal activity of every developer – and more over, one of the means that makes them getting better at coding by learning from their own mistakes.
Very often I hear idea of having separate teams that are only busy with bug fixing, so that the first team is not slowed down – as they say, and as a result of that thinking, the maintenance task is given to another group. This is what then usually happens:
  • This makes merging fixes a nightmare
  • The code that the guy is fixing in one release might be already refactored and moved to another place in the next release. Even better, since people know that this will be the issue, developers are discouraged from refactoring.
  • In such project setup, the source control is also used as a damage control tool, so maintenance team very often has no rights to work on the current release – therefore bug never gets fixed in the next release.
  • The best guy to fix the code is the one who wrote it, since new person can easily introduce new bugs (or wrong behaviors) not knowing the complete context
  • It will make development guys less caring about the quality of code they write
  • It will drag your resources in training another group anyway
  • This doesn’t necessarily has to be a big effort

So, in my mind, every developer should get fair share of new features and bug fixes in every iteration. And this should be planned like any other activity in the project. I would recommend having fixed time allocation for this activity in every iteration. How much you need per iteration and per release first time is hard to know, and in order to for you to get good at this, I need to introduce some other aspects of the product lifecycles first: release cycle, maintenance strategy and customer SLA’s, since without it, this story would not be complete. More about that and how to effectively plan maintenance tasks in your project – so that you keep your customers and developers happy, you can read in my next blog post.

Leave a Reply