Friday, September 21, 2007

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".

2 comments:

Unknown said...

I thought it's much easier than that. The very thing people hate about maintenance is fear. The fear to change something and break it, and then there's noone but you to take the blame (but, it's not yours). Fear of being stupid because you can't tell what the heck is in there, code is a mess, documentation is flawed and original developers left long ago. People are actually afraid of minefield projects, they probably just can't put it straight.

Serge Stepantsov said...

Wow! This is a great and simple explanation!

Probably, it's a background for most of them (most of us?), but a lot of people are still not ready to point it as a real reason of this hate. And there are still quite many cases, when a person starts hating project even if she/he works on it from the very beginning. Thus, fear can be the reason for hack-workers, grandma, and pseudo-researcher.

However, it looks like I missed at least one category in my classification. Someone like Tramp - a person, whose experience is mostly based on fixes and small improvements in others' projects. And this experience was mostly unsuccessful, without real chances to get excellent noticeable results. If they are successful no one pay real attention to these achievements, but if they crash something everyone blames them.