This topic should apply to software jobs regardless of the programming
languages.
I want to know if most of the software jobs in the market are software
maintenance (fix bugs, new feature enhancements on existing code)
rather than new developments (from scratch).
As others have noted, it is quite common to put new people onto
maintenance.
One of the posters suggested that this was training so that people
would learn the value of writing good maintainable code. Posters
might also have suggested [but haven't yet in my timeframe] that it
was an opportunity to give the new programmer a good understanding of
the project as a whole.
These two factors certainly apply, but there is another factor which
is often more important: maintenance is given to the new programmer
because in most power relationships, you give the unwanted tasks to
those who don't have the power to effectively refuse them.
In -every- programming environment i have worked in, the young
new programmers have chomped at the bit, eager to *write programs*,
and frustrated when they aren't given a program to write within a matter
of days. I have often seen new programmers upset that they aren't
creating new programs yet; often they would at least -say- that they
were thinking seriously of quiting because "this isn't what I
hired on for!" And most of them held that resentment of doing
maintenance (or even real formalized design specs), and pushed their
managers to rush into -new- -code-. Quite a few of them thereafter
refused to do maintenance as soon as they had accumulated enough
internal political capital to make it stick.
I've heard much the same thing from other people I know who are
in the software industry: most programmers really dislike code
maintenance -- even if it is their own code that is being maintained!
Most do not even like to do feature or design changes to their
existing code, not unless the change is clearly to add something "new".
Even to get someone to rewrite their code to make it faster
can be hard to convince them to do, unless you can make the situation
into a challenge to make their code run as quickly as possible...
a situation which often results in unmaintainable code that would
probably run slower on the next compiler over.
New programmers get stuck with maintenance because the more
senior people don't like to do maintenance. I've heard intermediate
people seriously tell their manager they would quit if they
were not given a "real" programming project.
The flip side of this is that it turns out that relatively few people
are actually -good- at maintenance. To be able to take existing code
(often poorly documented) and not only figure out what it -does- do,
but to figure out what it was -meant- to do, and to do massive
revisions to get clean code that does what it -should- do -- this is a
skill that I have rarely encountered. For a disorganized program of any
real size, it requires someone who is patient and an excellent mental
modeller, able to simultaneously hold in mind -many- program aspects
and relate them all to each other, seeing the overview of what is
logically consistant and yet able to pinpoint the minute details of
what does not fit. My experience suggests that the portion of
such people is less than 1 in 100 programmers; I'm not even confident
that as many as 3 in 1000 are good at this kind of work.