most software jobs are software maintenance rather than new development?

[.]

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?

Experience comes with exposure to code and coding. You cannot define it
merely by years.

I have seen people who approach their job as just a paycheque. They do
just enough not to get fired. Advancement comes from knowing history and
not being a good programmer.

On the other, some programmers love programming. When they go home they
log onto the WWW and participate in some online community (e.g. open
source project or reading newsgroups).

I would not be surprised to find a junior programmer with 5 years
experience and a senior programmer with 3 years experience. Depends on the
person not just the years in.

 

[BigBrian]

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.

I also
don't think that you should just wait around until you have more
experience, hoping that will help.

Hmmm, but the original poster admitted that he doesn't even know Java
well. Don't you think that knowing the language should be a necessary
requirement for any programming job?

Lets see.... He doesn't know java very well, but he has a job as a java
programmer. He gets assigned to doing maintanence ( IMHO a very good
opportunity to learn the language in addition to what is good and bad
design ), but instead he complains that he's not doing new development
( for which IMHO, given that he doesn't know the language all that
well, he's not qualified ). Then it seems that many people here
suggest the he look for another job ( instead of taking advantage of
his current opportunity to gain experinece/knowledge ). IMHO, there's
something wrong with this....

 

[Daniel Parker]

Hmmm, but the original poster admitted that he doesn't even know Java
well. Don't you think that knowing the language should be a necessary
requirement for any programming job?

You're referring to "my standpoint is that even I don't know Java well,
I still can do the work."

I didn't read that the way you did. I read it that even someone who
didn't know much about Java could still do the work that he's currently
being assigned, that the work isn't challenging.

-- Daniel

 

[Bradley K. Sherman]

You're referring to "my standpoint is that even I don't know Java well,
I still can do the work."

I didn't read that the way you did. I read it that even someone who
didn't know much about Java could still do the work that he's currently
being assigned, that the work isn't challenging.

And whose English is below par. No big deal if he's working
outside the USA.

I never hire programmers who scorn maintaining existing code.

--bks

 

[Skarmander]

"Flash Gordon" <[email protected]> wrote

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

To me "refactoring" is no more or less jargonic than "dangling pointer"
is, and I doubt the latter irritates. I'll grant you that many
programmers don't have a name for the specific activity, but that
doesn't disqualify the word.

It is true that the word was misappropriated here; "rewriting" is the
more inclusive term. Compare "rewriting from scratch" (meaningful) and
"refactoring from scratch" (nonsensical). When requirements change, you
rewrite. Refactoring is an internal affair.

S.

 

[John Bode]

Hmmm, but the original poster admitted that he doesn't even know Java
well. Don't you think that knowing the language should be a necessary
requirement for any programming job?

Well, my first real programming job as a freshout was in Ada, a
language in which I had *no* practical experience, and this was new
development, not maintenance. I had about two weeks to get proficient.

Granted, it was scutwork, but it was scutwork I had to develop from the
keel up.

So, no, knowing a specific language is not *necessarily* a requirement
for a programming job (barring things like numerical analysis or signal
processing or some other performance-oriented field, where intimate
knowledge of the implementation language is vital). More important is
a knowledge of programming fundamentals, coupled with an ability to
learn how to use new tools quickly (for a five or six year period,
every contract required me to learn a brand-new (to me) language or
API).

If you haven't been exposed to Java, but know C or C++, then that's not
that big a barrier. If you know one Algol-derived language, then you
ought to be able to pick up any other Algol-derived language with
little or no difficulty. If you're going from, say, Fortran IV to C++
(or vice versa), that may be a bigger problem, but even then the leap
isn't so great.

C to Lisp, now, that would cause some heartburn.

Lets see.... He doesn't know java very well, but he has a job as a java
programmer. He gets assigned to doing maintanence ( IMHO a very good
opportunity to learn the language in addition to what is good and bad
design ), but instead he complains that he's not doing new development
( for which IMHO, given that he doesn't know the language all that
well, he's not qualified ).

There are people I consider experts in specific languages that I would
not assign new development to, because they constantly go beyond the
scope of the spec or, better yet, ignore the spec outright and deliver
something really cool but really useless.

Getting to write new code has less to do with your familiarity with the
implementation language and more with your ability to spec and design a
solution, or at least to go from a spec to working code.

In the end, knowing the actual implementation language is a relatively
minor detail; understanding the application domain and how the code you
write fits into it is the more important thing.

Then it seems that many people here
suggest the he look for another job ( instead of taking advantage of
his current opportunity to gain experinece/knowledge ). IMHO, there's
something wrong with this....

FWIW, I think he should stick with his current gig for at least a year
or two, and get used to not only Java, but the application domain in
which he is working.

 

[Chris Uppal]

And whose English is below par. No big deal if he's working
outside the USA.

Do you care to rephrase that ? Or to recant ?

Otherwise do, please, include in your answer an exact description of what being
in "the USA" has to do with par (or above) English.

-- chris

 

[Flash Gordon]

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

Unlikely since I'm not interested in writing feasibility studies.

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.

Rubbish. As I mentioned I've worked on SW that was still maintainable
after many iterations of modifications. Sometimes I had to modify one of
our libraries to add functionality to allow me to modify a higher level
library to add functionality to allow me to add the required feature,
but I never had to do a complete rewrite of a function, module or the
program because we *designed* it to be flexible and maintainable.

(OK for massive systems this breaks down and you cannot rewrite the program
from scratch.

Ah well, through most of my career I've been working on SW that was more
than a man year of effort, sometimes vastly more. Sometimes you still
have to do rewrites of modules, programs, or entire systems.

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

Only if you don't understand the software you are working on. I've done
bug fixes that involved modifying both client and server of a
client/server application, and that obviously involved more than one
unit especially as client and server were written in different
languages. In fact, it was only three weeks ago I did this and I first
modified two functions within a module in the library, then modified the
application SW running on top of the library, then modified the client,
all to fix one system bug. It only took me half a day including testing,
so hardly a crisis. Oh, and since then no one has found any problems in
that area during heavy testing, not even the customers we invited in to
do their own testing.

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

Sometimes you can do a lot of refactoring with only small changes in the
code. For example, spotting that the application is doing basically the
same thing in a few places and moving that functionality down in to a
library. Or moving a piece of functionality from client to server. On
one occasion it consisted of doing a timing analysis and proving that
everything the SW was required to do could be done in the relevant ISRs
the moving the code around and tweaking bits to make the ISRs safely
reentrant (this was assembler), and I had the whole thing completely
restructured whilst changing under 10% of the lines of code. Other times
refactoring can involve a major rewrite.

 

[Keith Thompson]

I would not be surprised to find a junior programmer with 5 years
experience and a senior programmer with 3 years experience. Depends on the
person not just the years in.

Indeed. Some programmers have 5 years of experience. Others have one
year of experience 5 times.

 

[Andrew McDonagh]

Hmmm, but the original poster admitted that he doesn't even know Java
well. Don't you think that knowing the language should be a necessary
requirement for any programming job?

Lets see.... He doesn't know java very well, but he has a job as a java
programmer. He gets assigned to doing maintanence ( IMHO a very good
opportunity to learn the language in addition to what is good and bad
design ), but instead he complains that he's not doing new development
( for which IMHO, given that he doesn't know the language all that
well, he's not qualified ). Then it seems that many people here
suggest the he look for another job ( instead of taking advantage of
his current opportunity to gain experinece/knowledge ). IMHO, there's
something wrong with this....

Utter rubbish!

The project I'm leading is using Delphi7, VB6 & PL/SQL - none of which
I've used.

Knowing the languages helps - but knowing software engineering
principles and practices matter much more.

Once you have enough of a grasp on these, then moving to unknown
languages is trivial. The biggest learning task when moving to new
languages, is learning the libraries that they provide or are commonly
used - but this is simply fixed by talking to the guy next to you and
saying ' I want to do X - how do I do that in <insert your new language
here> '

Really, it is that simple.

Andrew

Andrew

 

[Ian]

And whose English is below par. No big deal if he's working
outside the USA.

? remember where the language came from!

Ian

 

[Roedy Green]

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

What is it in your definition?

 

[Bradley K. Sherman]

Do you care to rephrase that ? Or to recant ?

Otherwise do, please, include in your answer an exact description of what being
in "the USA" has to do with par (or above) English.

Sure, if you're working in Germany your English does not have
to be good. If you're working in the USA (or UK or Oz) it
should be.

--bks

 

[Andrew McDonagh]

What is it in your definition?

what is what, in my definition?

 

[Roedy Green]

The needs of the compiler

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

Let's say that an application programmer were in charge. He sets up
listeners all the time. He would insist on doing that in at most a
line of code, no matter how much work it meant for the compiler and
library writers.

In your IDE you would right click on the component and insert the code
right there.

If an application programmer were in charge there would be smart
components for all the usual business objects, names, address, emails,
website, zips, provinces, countries, .dates, phone numbers that worked
for all countries. They would automatically format and validate all
input. That would not be his problem any more than the strange rule
of date calculation are. Low and high bounds checking and all manner
of other common validation would be built into the declaration without
any procedural code.

If an application programmer were in charge , components would know
their labels, and there would be layout that would automatically
insert such labels when there was sufficient room, and would at
minimum divulge them with a hover.

If an application programmer were in charge, the integration of SQL
and Java would be much more seamless, much like the new features for
than in C#.

 

[David Alex Lamb]

what is what, in my definition?

I believe he means:
What is PairProgramming in your definition?

 

[Roedy Green]

Young hot shots are a major problem in a team environment. They are so
keen on doing something cool, they forget some lesser light will have
to later figure it out to maintain it. These types often refuse to
write any documentation at all, claiming their code reads like poetry
and does not need it, at least if everyone scrutinizing every line
lovingly.

These hotshots can still be useful. For example, I was team leader
on the first MacIntosh commercial app written in Canada, the CSL Stock
Charter, developed on the Lisa and wired over to the Mac for
execution. Apple's docs and code were unbelievably bad. Lots of "to
comes" and simply wrong information.

Our app was embarrassingly slow. The problem was obviously Apple's
first cut at a software floating point library. I figured out that the
scaling routines for the graphing were the major culprits. I handed
the Pascal version of the code to a hotshot friend of mine, and said,
"go to it. Do this same thing using integer fixed point scaling,
assembler, any dirty tricks you can think of."

He came back a few days later with some Motorola 68K assembler that
was about 2 orders of magnitude faster. Never would that code be
maintained. If the code were ported, it would be re-optimised from
the Pascal version, perhaps with hints from the 68K version.

 

[Roedy Green]

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,

That is an important observation. When you write new code, you can
focus 99% of your attention on the one class you are composing.

When you do maintenance, any change you make could potentially disrupt
ANYTHING in the whole app system. The better it was originally
designed, the less paranoid you have to be. You have to understand the
app as a whole and mostly what it is safe to IGNORE for any sort of
change.

In contrast, when you write new code, there are no interactions yet to
worry about.

I am big on Christmas present comments of the form, "If you have to
change X, or add a new Y all you need do is modify the tables/code at
a, b, c."

So you need a very focused mind for writing new code, and a mind that
can keep a million interactions in mind to do maintenance well.

I used to have a ritual for getting into heavy maintenance mode.
It involved consuming pizza and coffee, being undisturbed for long
periods of time, unusually late at night, re-rereading documentation
and refreshing my mind going over crucial code till a model of the app
as a whole was again fresh in my mind. Then I could make a great
series of changes very quickly and accurately.

Maintaining your own code is much easier. I can trust myself not to
pull a great many stupid stunts, and to thoroughly document iffy
tricks, and any crucially important gotchas. I can't do that
maintaining other people's code until I get to know them though their
code.

 

[Roedy Green]

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

Perhaps this is partly why there is so much outsourcing. People who
maintain their own code write better code.

 

[Roedy Green]

He doesn't know java very well, but he has a job as a java
programmer. He gets assigned to doing maintanence ( IMHO a very good
opportunity to learn the language in addition to what is good and bad
design ),

Getting paid to maintain the code of a master programmer is a bit like
being invited to sit at the lotus feet of your guru.

What an opportunity for education!

On the other hand, cleaning up code from incompetents will rapidly
teach you all the things not to do. I took out much of my frustration
from such jobs writing the most popular essay of my lifetime:
http://mindprod.com/jgloss/unmain.html with almost a million hits on
it now.

It hit a nerve.