IT Reflexions

21 Mar, 2011

Keeping up the team’s enthusiasm in maintenance projects

Posted by: Anca A. In: Career Management| Team Management

We all know maintenance projects keep the client happy and bring a reliable and often generous income to the company.

In a previous article I tried to explain some of the reasons that make maintenance projects so unattractive for many developers. I tried to show why for “passionate” (and not only!) programmers the dull IT projects are not very pleasing.

So, if we try to look from the other side, which are the best ways to keep people motivated when working in such projects?

Technical view

  • Learn how to debug, program better, optimize
  • Learn new skills and tools
  • Learn to write better specs
  • You are agile by default (due to rapid user response time)
  • Learn about the client’s business
  • Learn people skills or how to interact with users
  • Not very likely to be off-shored

Each of these points and not only have been very well described by Greg Jorgensen on his blog.

Managerial view

Rotate people after a while

This is actually the most intuitive action to do. The problem here is that it often takes an average of about one month for a new arrived person to be as efficient as the previous team member. Due to the fact that the client’s business knowledge is sometimes crucial for understanding the applications, it is usually required to stay at least one year and a half of work in such projects.
The problem here is that especially young developers tend to get bored after one year and a half of routine tasks.

20% of the time on a favorite project

Spending about 20% times on working on an interesting and challenging project that can provide new technical horizons, learn favorite technologies, put ideas into practice. This is actually the technique used by Google to help people cope with the dull tasks.

20% of the time in maintenance tasks

Spending less time in repetitive tasks would also be an option to allow team members to gain new skills and working in more challenging projects. By rotating them to take care of these tasks a certain day or week allows easing the feeling of doing the same thing daily. The problem here is however that the process knowledge is more diluted among more people and so a possible loss in service quality. The benefit is that the departure of a team member will have less impact in keeping the knowledge.

Use the project as a prerequisite for passing to more important projects

Proposing developers “to do their part” in the maintenance projects as a stepping stone for advancing towards their “dream project” can also be a good technique as long as it is a respected promise. However, if most of  the company’s projects are maintenance based it will be hard to provide everybody with their opportunity.

Put the top programmers in development projects and the lousy ones in maintenance

Some people are not motivated by taking new challenges every day and are comfortable with doing the things only the things they know on a daily basis. Their technical skills are average or maybe even limited. They are most likely the perfect candidates for the maintenance projects. So why not give the top performance the development projects and orient the rest in the more repetitive tasks? The risk here however is making the wrong guess and putting a “passionate” programmer in the wrong place for too long time.

Give benefits/financial motivations

Though this may sometimes be good option for encouraging developers to stay. More days off or  good bonuses from time to time can keep the spirits high.

1 Response to "Keeping up the team’s enthusiasm in maintenance projects"

1 | Yves Rutschle

March 23rd, 2011

Avatar

Ack, I already wanted to comment on your previous post but didn’t get time (or, rather, got distracted.)

I like the article you link to a lot, in part because I disagree with large parts of your argument (sorry :) ).

I feel like maintenance, in general, is a lot harder than development from ground. What’s hard with new developments is getting the specifications right, then getting the architecture right. While there is definitely a need for skilled architects, these do not tend to be the same people that do the actual development (in large companies, anyway).

So you have skilled software engineers that do the architecture, and others that do the development. And the actual programming is not that hard.

I am personally absolutely sure that reading someone else’s code is a lot harder than writing code from scratch, for a variety of reasons:

- It’s basically not taught in school
- You need to understand the intent of the code from what’s there, and in case of debugging work out how the actual code differs from the intent (in your own code you already know the intent)
- Reading code requires a more extensive knowledge of the programming language that writing it (if I only know 5% of Perl and avoid regular expressions because I don’t know them, I can still get by and write a Perl program. If I need to debug a program that’s been written by a Perl programmer that put regular expressions everywhere, I just have to know them).

This last point is linked to the “becoming a better programmer.” I spent quite a bit of time working within the Linux kernel a long time ago, and I know for a fact I learnt a lot of C from it.

And this brings me to my last point: anyone can write new code and make a small application (say, a thousand lines).With a good architect munching the work for you, you’ll be just putting a bunch of thousand-line programs together. However, finding a bug in a 2-millions line program (like the Linux kernel) is a whole different story.

Out of my programming experience, the success that I remember most was finding a bug in Linux, whereby “once every few days the clock goes back a minute or so.” (wtf?, is the normal first reaction.) Next in line was finding a bug in a Linux driver using an oscilloscope and good sight. Only after that do I rank full new applications, most new development being still boring and pedestrian anyway.

So, giving maintenance projects to poor programmers? I don’t know that’s a actually a good idea. On the other hand I will agree that maintenance and debugging have a generally bad reputation, but I reckon it’s mostly because it’s harder. Or that’s what we should tell people anyway to get new recruits ;)

PS . Nice new haircut!

Comment Form

Categories

Search


About me

Client-focused software engineer with high intellectual mobility and experience in international teams.

Some of my interests are open innovation, design patterns, networking, personal branding, blogging and study of foreign languages.

Enjoy your visit and don’t hesitate to leave me a feedback!


My upcoming trips

Copyright © 2007-2011 IT Reflexions is proudly powered by WordPress

Fervens - C Theme is created by: Design Disease brought to you by Smashing Magazine