most software jobs are software maintenance rather than new development?

[Malcolm]

Ah, that appears to be the tendency for many novice programmers doing
maintenance. Yes, sometimes code needs to be re-writen, but IMHO,
novice programmers are more likely to suggest it than seasoned experts.

Novices suggest rewriting the lot, experts try to salvage, seasoned experts
realise that this is usually a waste of time and go back to rewriting code
from scratch.

The fact is that you can patch code maybe once. Then the structure of the
code is destroyed and further patches introduce subtle and deep-seated bugs,
and then the project enters a cycle of decline. This is particularly the
case when patcher and original programmer are not the same person.

Also, generally fixes which are on the borderline between a bug fix and
adding new functionality tend to be marginal special cases, like support for
cars with temporary trade registration plates in a congestion charging
scheme, which violate the assumptions on which you have built the program -
in this case, that a car keeps the same registration number for its useful
life. These are particularly likely to introduce problems.

IMHO, sometimes managers really do make the right decision. Many times
their decision is based on business information that the programmer
doesn't have or doesn't understand. Moving on for something like this
is childish, IMHO.

Sure, however you probably don't have any shares in the company you are
working for, so what matters is the value of the experience you get doing
the work, and the immediate interest and enjoymnet of the work itself.
Enjoyable work tends to have high status, and future employers tend to look
for people who have held high status positions. Usually you win on both
counts.

So Robert isn't necessarily wrong.

 

[Andrew McDonagh]

On 20 Oct 2005 00:13:48 -0700, in comp.lang.c , (e-mail address removed)
wrote:



snipped.



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.

Hi Mark,

( Please note this reply isn't so much to yourself, its to all of the
posts that talk about 'cutting their teeth' - I'm not singling you out.)

You are (sadly) right it is common. Its also the worst way of
integrating and using new people - especially newly qualified developers.

We are asking the to fix bugs on existing systems, where they typically
won't understand the original designs or design trade offs that were used.

Its actually more difficult to enhance or fix bugs in existing code
bases in a safe manner which doesn't introduce defects, than it is to
create new 'green field' code, for most people.

However, the main problem is the mentality of it -
" you are the new guy so your have to prove your worth scum-bag.."

Crazy.

Its not something I tolerate on my teams.

I employed a person who hadn't done any development for a year and half.
They also hadn't done any Java - they are a smalltalk-er - but they know
a little OO.

He started on the team and by the end of the first week was developing
and being productive.

Now some of this is down to the teams principles and practices:

Collective Code Ownership - the new guy wasn't assigned an area or role,
he is part of a team where everyone works on all areas, maintenance and
greenfield.

Pair Programming - all development work being done in pairs meant that
he didn't need any ramp-up time to become useful - he paired with one of
the other team members and they worked together upon a single task, side
by side, swapping the keyboard as and when they wanted. The knowledge
transfer to the new guy is very quick this way and the other team person
learned some new skills from the new guy.

TestDriven Development - as we use TDD to design our system, any changes
the new guy and his pair make, are automatically regression tested by
the suite of unit tests. Their own design artifacts (their unit tests)
for the new code changes are simply added to the big pot of existing
designs.

there's more I can add if you want...

Andrew

 

[Mike Wahler]

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

Almost all jobs in almost every discipline are 'maintenance'.
For example, how many people build automobiles? How many
people repair automobiles? Until someone figures out how
to build perfect products that stay perfect forever, I
suspect this will be the case.


-Mike

 

[Flash Gordon]

Novices suggest rewriting the lot, experts try to salvage, seasoned experts
realise that this is usually a waste of time and go back to rewriting code
from scratch.

No, they judge each case on its merits.

The fact is that you can patch code maybe once. Then the structure of the
code is destroyed and further patches introduce subtle and deep-seated bugs,
and then the project enters a cycle of decline. This is particularly the
case when patcher and original programmer are not the same person.

Not necessarily if the SW was properly designed in the first place with
appropriate allowance made for likely future use. Before anyone says
this is not possible, I know through personal experience that some of
the time it *is* possible. I've taken code that was well designed by
someone else, modified by that person many time, modified it myself many
times, then passed the maintenance on to other people.

Also, generally fixes which are on the borderline between a bug fix and
adding new functionality tend to be marginal special cases, like support for
cars with temporary trade registration plates in a congestion charging
scheme, which violate the assumptions on which you have built the program -
in this case, that a car keeps the same registration number for its useful
life. These are particularly likely to introduce problems.

Some times requirements change enough for things to need refactoring,
sometimes not.

<snip>

 

[Roedy Green]

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.

I heard one estimate that a program gets ten times as many hours spent
maintaining over its life that it does getting originally written. So
obviously maintenance predominates over initial coding. :There must be
many more maintenance jobs.

You may have noticed that programmers tend to be unusually
egotistical. This is part of the reason they generally don't like
modifying other people's code. They have to leave most of it "ugly" by
their personal scheme of aesthetics. It is a cause of stomach
wrenching unhappiness. They want to write virgin code so they can do
it "properly" or "their way" depending on your point of view.

I bugs me that languages don't seem to take maintenance into
consideration in design. The needs of maintenance programmers are
very low on the totem pole. The needs of the compiler writer trump
those of the package writer trump those of the application code trump
those of the maintenance programmer.

However, nationally advertised jobs tend to be the higher paying ones.
Here they are looking for experienced team leaders, architects etc.
not mundane maintenance programmers.

I think a bumbling incompetent could get by in a maintenance job
simply because the deadlines are not as tight and nobody really knows
how long it SHOULD take to find a bug or make some change. In theory
it should be easier, but managers don't put nearly as much weight on
efficient maintenance as getting the project up and going while the
spotlight is on it.

 

[Roedy Green]

Pair Programming - all development work being done in pairs meant that
he didn't need any ramp-up time to become useful - he paired with one of
the other team members and they worked together upon a single task, side
by side, swapping the keyboard as and when they wanted. The knowledge
transfer to the new guy is very quick this way and the other team person
learned some new skills from the new guy.

It is quite amazing how even a rank novice can become quickly useful
so long as he or she can type.

I would let them work first pretty well just as a typist as I went
about my usual business of writing and maintaining code. Most of this
was totally mysterious. But almost imperceptibly I could use a shorter
and shorter set of verbal commands to get the text I wanted written.
They learned much as a child learns a new language. You get to the
point where you could say something like. Write me a class with fields
x, y, z of the obvious types and do the usual constructors and
get/set.

Validate with configurable bounds.

Now adays you would do this with an IDE template, but people don't
need to be taught the template in excruciating detail, and they can do
theme and variations with little trouble. They can also convert old
code to a new pattern.

 

[apngss]

Most posters say that companies usually put new programmers, or less
experience programmers to do the maintenance work.

One fundamental question that bothers me: How do we define "experienced
programmer"? 5 years experience, 10 years? I mean, how many years of
experience are considered as an experienced programmer?

 

[Dag Sunde]

Most posters say that companies usually put new programmers, or less
experience programmers to do the maintenance work.

One fundamental question that bothers me: How do we define "experienced
programmer"? 5 years experience, 10 years? I mean, how many years of
experience are considered as an experienced programmer?

How many years would you consider if I asked you about an experienced
mason, carpenter, mechanic or electrician? or a woodenboat builder for
that sake?

Its a craft, and is about the same thing.

 

[Walter Roberson]

:Most posters say that companies usually put new programmers, or less
:experience programmers to do the maintenance work.

:One fundamental question that bothers me: How do we define "experienced
rogrammer"? 5 years experience, 10 years? I mean, how many years of
:experience are considered as an experienced programmer?

Depends on the company. I've been programming for more than 25 years,
and the programming task that is waiting in the wings for me is
essentially maintenance work. On the other hand, if they thought
someone else could do this particular task well, they would have handed
it on by now instead of waiting for me --- there are some things that
effectively require very experienced maintenance programmers!

I no longer recall whether I was put on new code during my first
work term; I believe I was by my second, and I was doing some pretty
hairy work by my fourth.

But a lot depends on circumstances and skills and personality.
If the organization is "pushing" the progress of a fair sized project,
then the organization very likely is short of people who can readily
visualize diverse parts of the system and piece those parts together,
so anyone who displays an obvious talent in that field might find
themselves doing integration code development that most people with 5-10
years experience would hesitate to begin. But the skills and temperment
that make one a "natural" at that kind of integration code development
are pretty much the same as those that would be displayed by
a "natural" maintenance programmer/analyst.

So... in at least some organizations, you get to the top faster by
being good at maintenance than you do by being indifferent at
maintenance but good at creating new work by yourself.

 

[Martin Eisenberg]

I bugs me that languages don't seem to take maintenance into
consideration in design. The needs of maintenance programmers
are very low on the totem pole. The needs of the compiler
writer trump those of the package writer trump those of the
application code trump those of the maintenance programmer.

Can you please expand on that for someone without extensive exposure
to old code?

 

[BigBrian]

Novices suggest rewriting the lot, experts try to salvage, seasoned experts
realise that this is usually a waste of time and go back to rewriting code
from scratch.

I completely disagree. This is how people who think they are seasoned
experts behave. I have seen this happen several times, and invariably
it takes longer to do the rewrite.

The fact is that you can patch code maybe once. Then the structure of the
code is destroyed and further patches introduce subtle and deep-seated bugs,
and then the project enters a cycle of decline. This is particularly the
case when patcher and original programmer are not the same person.

I agree that it's usually easier for the original programmer to do the
maintenance, however I disagree with the "only patch code once"
comment. Depending on what you mean by "patch", but if this is the
case, then the original code was a big pile of poop and not worth
anything to start with.

 

[BigBrian]

You may have noticed that programmers tend to be unusually

egotistical.

Isn't that the truth.

This is part of the reason they generally don't like
modifying other people's code.

Sad, but true.

They want to write virgin code so they can do
it "properly" or "their way" depending on your point of view.

... and then leave the project ( They're off design another project ) to
a group of other people how have to deal with the big pile of poop that
they implemented, and do the real work of getting everything working
correctly. ( No, I'm not bitter, LOL ) No, acutally, I like doing
maintenance ( and new development ).

 

[Cristiano Sadun]

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!

This is odd. I dont know what "most programmers" do - and I'm not
particularly questoning your assertion - but I think one of the best
indications about how good a programmer is (or how well designed
his/her programs are) is exactly how easy it is to maintain them -
adding features, enhancing existing ones etc.

It would really be a sad world if most programmers wouldn't like/accept
to do that..

 

[Phlip]

Most posters say that companies usually put new programmers, or less
experience programmers to do the maintenance work.

One fundamental question that bothers me: How do we define "experienced
programmer"? 5 years experience, 10 years? I mean, how many years of
experience are considered as an experienced programmer?

What will you do with the definition? "Allow" the programmer to write new
code?

I think experience comes from eating your own dogfood - from maintaining the
code you yourself wrote.

 

[timjowers]

JavaDoc. Design documents. Lots of self-promoters decry specifications
and documentation because they never had to maintian a few 100k lines
of code where they walked in cold with no knowledge of the code. Bug
fixing in an OS is tough but at least OS theory is well studied and
documented. Maintaing a huge corporate app where the requirements are
often only verbally understood by a few people who may no longer be
there is really tough.

Good logging of ALL errors. Ability to turn on DEBUG logging and
preferrable at various levels of verbosity.

A large source base with an integrated unit test to test all of the
code is very nice.

Elegant design. Repeated design when functionality is repeated.

BTW, newbies should be willing to perform maintenance for a time but
if you have an MS CSci. then don't insult yourself or your University
by maintaining some scrap code written by a hacker. Look for a company
where legitimate software design and development is occurring. The
market is far too overloaded with keyword programmers and architects
who think every design looks like some pattern from a vendor's promo
conference rather than consider design as part of the trade and apply
an appropriate design to the appropriate problem. You're probably
maintaining bloatware written atop some consultingware appserver or
other infrastructure. The engineering mindset of solving the problem
with the lowest cost effort is rare in this industry. That's why the
term "Software Engineer" is no longer used. The managers prefer
"Programmer" and "Consultant" because it hides the fact that good
software development requires real engineering. Does your code
represent the Unix mantra of Keep It Simple Stupid?

Best wishes,
TimJowers

 

[Daniel Parker]

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). This is my first job as a
Java programmer, but I really don't see I do much Java development, all
I do is to fix bugs, and add some new features for new builds. Well, of
course I need to understand the logic of existing code, but my
standpoint is that even I don't know Java well, I still can do the
work.

I think that's been the case for a long time, and is exasperated now
because there is so much legacy software, and because companies today
are buying more and building less. In place of new software
development you now have integration projects that involve building
many small things to tie bigger things together.

But you want to do new development. I don't think that maintenance
work naturally leads to new development work, maintenance programmers
do important work, and there's a tendency to leave them there. I also
don't think that you should just wait around until you have more
experience, hoping that will help. Instead, do whatever it takes to
get into a new development environment. Sacrifice income and job
title, enlist the help of agencies and friends, scour the market, find
companies that need to do things and position yourself to get in there.
Make that your number one priority and go for it.

-- Daniel

 

[John Bode]

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). This is my first job as a
Java programmer, but I really don't see I do much Java development, all
I do is to fix bugs, and add some new features for new builds. Well, of
course I need to understand the logic of existing code, but my
standpoint is that even I don't know Java well, I still can do the
work.

Is that normal in my case? Or I am just unlucky...

Please advise. thanks!!

This really depends on the field and the individual company. For a
small, startupish company, you're almost guaranteed to be doing new
development regardless of the field. For a large, relatively mature
software company, it's much more likely that maintenance is the primary
focus, unless that company is making a major push into new areas.

I think your case is probably normal. After a few years of experience,
you should be able to aim for new development roles.

 

[Andrew McDonagh]

It is quite amazing how even a rank novice can become quickly useful
so long as he or she can type.

I would let them work first pretty well just as a typist as I went
about my usual business of writing and maintaining code. Most of this
was totally mysterious. But almost imperceptibly I could use a shorter
and shorter set of verbal commands to get the text I wanted written.
They learned much as a child learns a new language. You get to the
point where you could say something like. Write me a class with fields
x, y, z of the obvious types and do the usual constructors and
get/set.

Validate with configurable bounds.

Now adays you would do this with an IDE template, but people don't
need to be taught the template in excruciating detail, and they can do
theme and variations with little trouble. They can also convert old
code to a new pattern.

I confused by your reply - are you attempting to describe
PairProgramming - if so you are way off.

 

[Andrew McDonagh]

I confused ...

should have been 'I'm confused....'

 

[Malcolm]

No, they judge each case on its merits.

Sounds reasonable.
In fact you'll pretty soon spend your time writing feasibility studies
instead of actually programming.

Glance at it. If it is obviously a simple typo or slip then fix. Otherwise
rewrite the function from scratch if it's that sort of bug, and rewrite the
program from scratch if it isn't.

(OK for massive systems this breaks down and you cannot rewrite the program
from scratch. If a bug affects more than one unit then you need to tell
management that their program is in crisis, and fixes are extremely likely
to introduce new bugs.)

Some times requirements change enough for things to need refactoring,
sometimes not.

Rewriting. Jargon helps your credibility in certain types of organisations,
but on this ng it just irritates.