Why more people are crazy about development more than maintanence

[vjy chin]

I was wondering and seeing various posters posting they are really interested in only development and not maintanence.

Why is this so? I would say, that you can learn in both the fields, not alone in development.

Any ideas to what you like and why?

Thanks

[Anand Prabhu]

Maintenance work becomes routine once you get to know the system. But development usually involves new designs, new technology, new ideas etc. So the chances of going up the ladder are higher.

[Ulf Dittmer]

Anand is certainly right that developing new systems is more "glamorous", and interesting from a techncal perspective. However, I disagree with the conclusion that it helps career-wise. Prove to me that you can build a complicated system from scratch, and I'll be impressed. But prove to me that you can build a complicated system that is maintainable -or, even better, that doesn't need much maintenance-, and then I'll really remember next time I'm considering raises/promotions.

[vjy chin]

I agree it becomes more of a routine, but still may be one can try out the new ideas in place of old ones. May be one can make the system more faster, more scalable and so on.

Since in maintanence, you will really have the experience to see how the system works on what is designed, but in development you can only speculate about how it works.

But I would say one has to have experience in both the fields to really grow in career.

Thanks for the replies.

[Anand Prabhu]

Originally posted by vjy chin:
I agree it becomes more of a routine, but still may be one can try out the new ideas in place of old ones. May be one can make the system more faster, more scalable and so on.

You are mixing up maintenance with refactoring. In a maintenance project, usually, you would not be making major changes to code. Remember code changes involve the software lifecycle including regression testing. To make a system faster and more scalable, you would need good experience and also, it would be better if that is built into the system at design stage and not in production/maintenance mode. If the system is in production, that means it has passed the unit, integration, load and network tests. Yes, there is always scope for fine-tuning the system but unless one has developed systems, it will be difficult to get to the guts.


Since in maintanence, you will really have the experience to see how the system works on what is designed, but in development you can only speculate about how it works.

In a maintenance mode, especially if you are debugging something, it is possible to know how the system works. And you will debug only if there are problems. I do not think people usually take maintenance projects and run it on local machines for a long time to see how they work. You will be bored in no time. No one will want to go through the zillion jsps, servlets, EJBs, properties files line by line or by memory and figure out how they run. I don't understand what you mean by speculation in development. Are you referring to any assumptions made while developing code? You mean, the developer develops code and speculates on how it works? I definitely would fire such a developer before he destroys my project. Development also involves requirements gathering, systems and technical analysis, coding, testing etc.
[/QB]


But I would say one has to have experience in both the fields to really grow in career.

Thanks for the replies.
You are correct here. I always encourage the new entrants to learn all aspects of software cycles to get a good understanding of the entire lifecycle and that includes maintenance. That would give a broader picture.

[Deepak Bala]

I found maintainance to be challenging. Every change that the client wanted was like a complete SDLC. Gather requirement -> propose solution -> get it approved -> code -> test -> sit back and relax. Fortunately i was working on different applications so it was cool and not so boring.

[Jeroen T Wenting]

maintenance can be challenging, but mostly it consists of changing the length of an input field or fixing a spelling mistake in a screen.

It quickly becomes tedious and boring work.
As an example we did a major database change here a few months ago. That involved adding a single field to some 350 database tables, and updating about 2000 sources to query that field in order to decide whether records read were to be processed or not.
Effectively that meant adding a single field (and always the same one with almost always the same value) to some 5000 SQL queries.
Hardly challenging work (the biggest challenge was writing the editor macro that would add the code for me when positioning the cursor at the desired spot).

[M Movilogo]

At the initial phase of work, people fuss about dev vs maintenance.
After few years, all they will care is money

[Karthik Guru]

We have inherited tons of code from our parent company in the US that has no javadoc comments whatsoever , no design doc - nothing at all. So maintaining such code could be a real pain. Luckily the code itself is not that bad.

Now when a customer asks for a feature request/ a bug fix, we try to figure the whole architecture by stepping through the code. Now that we know the architecture, we are documenting it. Maintanence c'd still be ok if the people who developed it in the first place realize that the code that they developed continues to live on even after they leave. But unfortunately this is not so common.

[NDP Prasad]

Maintainence is quite boring. For example i have a change request case in my project, it will take time to know the code. You cant get help from the people who developed the code,because they(same team) may not be there. so we need to understand the Application first and then the code, It will make you unintersting.

For a Non CMMI company it is a hell.




This is what iam doing now

[vjy chin]

I also understand it becomes boring after sometime. But I would prefer the starting guys to get some maintanence experience before they come to development.

Also most of the maintanence code is without proper documentation and getting to know the whole application would be interesting, some may differ here.

In maintanence, the person get to know the goods and bads of the written code, so he might use them when he do the coding.

But finally it comes down to personal preference. Some want development, some want maintanence, but I would prefer both.

Thanks again for all the replies.

[Jeroen T Wenting]

doing maintenance on other peoples' shoddy undocumented code also gives you that much more appreciation for the need to write decent well documented code yourself
Of course it might also instill an attitude of "noone else does it so I don't have to either".

[vjy chin]

I agree, it can work both ways depending on the individual. But lets hope it works the right way, so the others would get a decent piece of code to work with.