No its normal, at least in my experience. New development is much more
interesting of course, but you likely to need a little more experience
before you get given jobs like that.

Not relevant to you (I'm sure) but I heard a funny phrase recently, a
newbie programmer was given a couple of Java classes to develop from
scratch. After a while he delivered these new classes and promptly got
taken off the project because his code had 'logic issues', he's bug
fixing now.

john

To have work?  No.

Perhaps you are undeserving, ungrateful and extremely
self-centered*, but unlucky?  No.

* To think your problem is so important that it justifies
cross-posting to such a wide range of groups.

Now GET BACK TO WORK.

Theres a large body of existing code out there. Ergo there must be
lots of jobs maintaining it. Its impossible, given the length of time
that computing has been around, for new work to be larger than old
work.

You're the new boy. Its commonplace for newbies to spend a lot of time
fixing bugs, it lets them cut their teeth, explore their abilities and
so forth.

It's normal. It's something of a privilege to work on a new project, and  
especially when you're new you'll tend to get stuck on the fixing jobs,  
simply because there are usually more fixes to be done.

There probably is a lot more maintenance going on than new construction.

But I would hope that most shops would expect new programmers to do a fair
bit of maintenance before they do new development.  Its pretty easy to
design cool new stuff without any consideration for what it costs to own
that code.  If you spend some time getting beat up by other people's
mistakes, you are less likely to make those mistakes on your own.

..

apngss wrote:

Ideally, all software projects should deploy to real users as soon as
possible. Then all further development is "maintenance", because you must
preserve existing (good) features while adding better ones. That depends on
clean code.

In your case, you are probably unlucky. Much software was written in a big
rush, under the belief that the software can't deploy until it has enough
features that customers will buy it and then use it through long maintenance
cycles. So the code has lots of bugs and a poor design.

The next AntiPattern in our industry: Managers then put the new guys into
maintenance, because it's slow burn. The hot-shots who wrote the bugs and
the poor design get rewarded with new and more lucrative projects.

Install JUnit, and start these policy:

- capture bugs with tests. Write new test cases
   to capture every bug before killing it

- as you learn about the code, refactor - just a
   little - to clean it up

That effort allows the code to get better over time. When you fix a bug, do
not throw away the knowledge that is fresh in your head write now. Invest
that knowledge back into the code by improving its test resistance.

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.