A few days ago I went to a meeting with a bunch of guys that were working in a maintenance project for a big international company. They looked exhausted, annoyed and had a hard time in finding “the joys of the craft” in their work. They had a hard time explaining me why they liked they work. Yees… “The team is great” and yes “It’s a big client, paying good and on time” and yes, the company “has a great canteen”.
And yet, despite all this, I got to wonder why is it that they don’t seem to enjoy the project they were working in. Actually, being myself involved in maintenance projects, it happened to me to ask myself how one could boost the enthusiasm of the people working in such projects.
So I started by trying to figure out what would make them happy when working as programmers (leaving aside the material incentives like salary, good food at the canteen).
The first thing that came in my mind was what , Frederick P. Brooks wrote in his “The mythical man-month” , about the “joys of the craft” when programming :
1. The sheer joy of making things
2. The pleasure of making things that are useful to other people
3. The fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles
4. The joy of always learning, which springs from the non-repeating nature of the task. In one way or another, the problem is ever new, and its solver learns something
5. Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff […]. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself.
But what is wrong with maintenance projects and why such a disgust at tackling one, especially for the young programmers?
We all know that maintenance, especially the traditional type, the “corrective” maintenance, is a vital part of a software application lifecycle and the clients pay well for keeping it perfectly working.
But from the passionate programmers’ point of view, we can easily see that some of the “joys” listed above cann’t be applied:
No longer creating something
You may do small fixes from time to time to correct a bug that showed up over night, but you are not creating much. You are probably keeping alive something that should have disappeared/evolved a long time ago. It often happens that an application has gone well beyond its retirement time.
Often repetitive and dull tasks
You are performing often simple and repetitive tasks on old technologies so apparently you don’t learn much because you learn something that you think is not useful.
Deciphering the puzzle
The complex “puzzle-like mechanism” it’s no longer created by you, but it’s for you to decipher and you often might find it not too logical. Maybe the application has not been well developed, or maybe it has been maintained by others, or maybe the client required new features that forced the developers to adopt a non-healthy approach just for the sake of not making too many changes and thus respecting the budget.
Periods of inactivity
You can be lucky enough to have your hands “full” all the time, or you can experience peaks and lows in your activity according to the client’s schedule or the good-functioning of the application. So, you have some time to fill up and you wonder what to start with and if you’ll have time to finish it.
Tight and rigid schedules
You have tight schedule constraints as one must be available at well established hours.
