Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > most software jobs are software maintenance rather than new development?

Reply
Thread Tools

most software jobs are software maintenance rather than new development?

 
 
Malcolm
Guest
Posts: n/a
 
      10-20-2005
"BigBrian" <(E-Mail Removed)> wrote
>
>> If you really want to be a programmer,
>> ask your supervisors if you can re-write the bad code.

>
> 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.
>
>> If they won't let you do that, consider moving on.

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


 
Reply With Quote
 
 
 
 
Andrew McDonagh
Guest
Posts: n/a
 
      10-20-2005
Mark McIntyre wrote:
> On 20 Oct 2005 00:13:48 -0700, in comp.lang.c , http://www.velocityreviews.com/forums/(E-Mail Removed)
> wrote:
>
>



snipped.

>
>>This is my first job as a
>>Java programmer, but I really don't see I do much Java development,

>
>
> 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
 
Reply With Quote
 
 
 
 
Mike Wahler
Guest
Posts: n/a
 
      10-20-2005

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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


 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      10-20-2005
Malcolm wrote:
> "BigBrian" <(E-Mail Removed)> wrote
>
>>>If you really want to be a programmer,
>>>ask your supervisors if you can re-write the bad code.

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


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>
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-21-2005
On Thu, 20 Oct 2005 10:57:53 +0100, Mark McIntyre
<(E-Mail Removed)> wrote or quoted :

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

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-21-2005
On Thu, 20 Oct 2005 23:17:55 +0100, Andrew McDonagh
<(E-Mail Removed)2s.com> wrote or quoted :

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




--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
apngss@yahoo.com
Guest
Posts: n/a
 
      10-21-2005
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?

 
Reply With Quote
 
Dag Sunde
Guest
Posts: n/a
 
      10-21-2005
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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.

--
Dag.


 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      10-21-2005
In article <(E-Mail Removed) .com>,
<(E-Mail Removed)> wrote:
: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.
--
Programming is what happens while you're busy making other plans.
 
Reply With Quote
 
Martin Eisenberg
Guest
Posts: n/a
 
      10-21-2005
Roedy Green wrote:

> 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?

--
Quidquid latine dictum sit, altum viditur.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
most software jobs are software maintenance rather than new development? apngss@yahoo.com C Programming 131 11-12-2005 07:23 PM
most software jobs are software maintenance rather than new development? apngss@yahoo.com Java 124 11-12-2005 07:23 PM
JOBs............JOBs............JOBs hardikh2000 Python 0 08-16-2005 03:55 AM



Advertisments