Maintenance and Development... The difference?

"I do not want to work on a maintenance projects", - that's what can be heard from software developers and from candidates quite often. At the same time, most of them can't describe their understanding of the difference between project maintenance and project development or, in other words, the difference between the things they don't like and that they do like.


Project maintenance phase "description"

Below is the list of items that people use to describe the project maintenance phase:

1. Bug fixing
2. In few months after beginning of the project
3. When software architecture is ready
   
4. After the 1st public release
5. When you have to update other's code

So, every project, that is being developed for some time by two or more programmers and that has not failed yet, is a maintenance project, isn't it?


Why it happens

Actually, I was not satisfied with this simplified answer that every project is a maintenance stuff, so I tried to get more information about people, who insists that hates those maintenance projects. After collecting and comparing the results during a period of 4 years, I've come to the following classification:

• Husband is the developer, who works on some particular project from the very beginning, who came through a set of successful public releases, who knows about that product and its code everything. Such persons can be stuck to the project for quite long period of time and fill comfortable enough. However, one day can start "a middle age crisis". This can be a good push for "starting new life". After this point, Father hates even an idea to be involved in new long "engagement". Such crisis can be very short or long enough, but in most cases the person returns to its habits and becomes ready again for new "long relationship".
• Researcher always tries to improve something. He spends part of his work day performing planned activities, and other part looking for new information, trying different technologies. This person can be really bored by the project if it requires 100% of his time and doesn't allow experiments. A lot of people pretends to be researchers, however only very small percentage of them really are. Most projects are still OK for a researcher, because most projects are happy about introducing something that improves the result. Maintenance projects are even a land of plenty for research, because they usually do have some time for improvements. If it's not the case, then it's better to use the researcher on a different task.
• Grandma is a person who pretends to be bored spending a long period of time on similar tasks. However, such developer does nothing to change it. Such kind of a person continue using a rotary phone and hate it, but won't try a button one because "it's too complex" and she "doesn't know how".
• Pseudo-researcher is a middle between Researcher and Grandma. Such person isn't afraid of reading some new documentation, however she/he used to reject most innovations because "there is too late to integrate them into existing project". I'm sure that you heard a lot of times a phrase like: "Well, the idea/solution is really good, but it's impossible to use it on current projects because [...here some generic explanation, that fits all current company projects, goes...]. Let's utilize it for our next projects".
  
• Hack-worker is a programmer, who didn't use to do his job in workmanlike manner. Doesn't matter, if he joined the project from the beginning or when some parts had been ready. This person performs activities ignoring all circumstances, which are not directly covered by the task description. If he needs to paint a wall, he'll never be worried about keeping the floor clean. Fixing a bug, such person can create two or three new. After some period of time, when the number of project-related problems becomes quite high, hack-worker starts hating the project, and other "maintenance" projects. His favorite is to start the project and to leave it before bugs have been revealed.

What is it all about?

Good question... This analysis is one of few things that I had done before I realized how to use the results. So I was just collecting the statistics because I was interested in finding a real reason that stays behind hating "maintenance activities".

But one day, when I was involved in consulting activity related to hiring process in a company that had several software project of different kind, I returned to the same question and found out a way to use this info.

As a result, we prepared a set of questions which helped the company to classify job applicants in one of 6 ways^*, and then select appropriate project for particular candidate or do not make an offer at all.

--
^* 6 ways are 5 groups listed above + people who doesn't make too significant different between programming and "maintenance".

Formula for Success

While reading Eric Sink on the Business of Software, I've found a quote that very closely deals with one of my first posts in this blog, the one about mistakes and activities:

Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. You are thinking of failure as the enemy of success. But it isn't as all. You can be discouraged by failure - or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember, that's where you will find success.

Thomas J. Watson, Sr., founder of IBM