Software Development: maintenance vs. hardcore coding

[Roedy Green]

If people are so clueless they can't get themselves out of a
self-created pre-processor mess, perhaps they should realize this is the
wrong profession for them. We don't all aspire to be brain surgeons, so
why should everyone have the right to be a software engineer?

You still have to decide whether the world as a whole will be better
off with a safe or dangerous tool. You have a choice about the tool.
You don't about the presence of incompetents.

I think the solution will be a specialised preprocessor to do JUST
that needed for maintenance and no more.

 

[Roedy Green]

yes of
course, you can't switch on them *at* *all*, so this problem doesn't arise,
so this is "better" isn't it.

With JDK 1.5 ones, you can. see http://mindprod.com/jgloss/enum.html

They have it pretty well correct, though sets are not as convenient as
Pascal's.

 

[Stephen Kellett]

Ah, Sir has failed to spot how you are "supposed" to do this in Java.

I suspected as much

What do the BCS have to say on this issue? And would their answer
validate?

Stephen

 

[Sam]

I used to maintain Java programs in my job. I am just assigned a new project
and require to develop the application from scratch. I realize my coding
speed is much slower than when I was in college one year ago. I suspect
the rationale is that mainteance is based on the existing program structure,
but coding from scratch requires lots of practices. My conclusion is
hardcore coding really requires programming skills, but not necessary
ture in code mainteance.

What do u think?

I've done a lot of work on both sides now (hmmm, that reminds me of a
song...never mind). I think maintenance is tougher because to do it
well you need to figure out how the code works - but not everything,
just the part that affects your change. If you understand it well,
depending on the change you can sometimes do it with just a line or
two of code, saving major chunks of time. Unfortunately, you may not
be appreciated for it because then management just figures it was a
simpler change than they originally thought.

Too many developers write complicated code, thinking how impressive it
looks. It's easy to write complicated code - making it simple is much
more difficult.

Much of "new" development consists of (or should consist of) cobbling
together various pieces of software and packages in a manner such that
the desired results are attained. Massive time-savings can be achieved
if such an approach is used.

To be honest, I hardly ever write code from scratch. I will usually
find an example somewhere (e.g. Roedy's site) and start expanding on
it. Then go back and refactor until you're satisfied with not just the
results, but the quality of your code as well. In all liklihood,
you'll end up being the maintenance programmer for a period of time,
so you might as well make it as readable as possible.

Regards,
Sam90

 

[Roedy Green]

I've done a lot of work on both sides now (hmmm, that reminds me of a
song...never mind). I think maintenance is tougher because to do it
well you need to figure out how the code works - but not everything,
just the part that affects your change. If you understand it well,
depending on the change you can sometimes do it with just a line or
two of code, saving major chunks of time.

In maintenance, the trick in figuring out what you can safely ignore.
The regional coders often imagine maintenance programmers have time to
thoroughly understand every line of code. They further imagine it the
code will be just as lucid to the maintenance programmer 2 years later
as it is to them now. "It does not NEED comments. It is sheer poetry."
Yes, Finnegan's Wake.

Any hints to what you can ignore or coding styles to make very clear X
cannot possibly affect Y are greatly appreciated. When in doubt, use
local or private variables and methods.

Other kindnesses are, "If you need to add another x, then you will
need to modify or review the code at a, b, and c. If you change the
way this method works, make sure you don't inadvertently break the
code at Z.

For what not to do, see http://mindprod.com/jgloss/unmain.html

 

[Stephen Kellett]

You still have to decide whether the world as a whole will be better
off with a safe or dangerous tool. You have a choice about the tool.
You don't about the presence of incompetents.

I have to disagree with you Roedy. Using an extension of that logic I'm
entitled to practice brain surgery. I'll be incompetent for sure, but
hey, who cares?

Stephen

 

[Tim Ward]

With JDK 1.5 ones, you can.

Unfortunately this isn't a sufficient improvement to cover the cost of
upgrading current projects, but yes, it will be better in the future (once
1.5.1 or whatever has settled down).

 

[Roedy Green]

I have to disagree with you Roedy. Using an extension of that logic I'm
entitled to practice brain surgery. I'll be incompetent for sure, but
hey, who cares?

It is a matter of degree. Extending your logic, there would be nothing
wrong with selling electric appliances with bare wires exposed.

You have to look at the ACTUAL effect on the planet of your action. Do
you cause more harm that good with your safety measure or lack of
safety measure?

The C experience showed that an preprocessing did more harm than good.
So if it is introduced to Java, it should be done in a way less likely
to be abused.

 

[Stephen Kellett]

The C experience showed that an preprocessing did more harm than good.

This is where we disagree.

Besides I have not been arguing for a preprocessor, just support for the
#ifdef and related conditionals built into the language. I am not
arguing for macro substitution, which is where most problems with C and
C++ preprocessing come from.

Stephen

 

[Roedy Green]

Besides I have not been arguing for a preprocessor, just support for the
#ifdef and related conditionals built into the language. I am not
arguing for macro substitution, which is where most problems with C and
C++ preprocessing come from.

I think then we agree more than you thought. I argued too that the
full C++ preprocessor was not the way to fly because of potential for
abuse.

I too argue for ability to do some conditional compilation. What ANT
offers might be just about right to discourage people getting too
fancy pants.

As soon as you bring in a preprocessor you have two listings to study,
before and after preprocessing. In C++, the preprocessor makes BOTH
more complicated than the equivalent Java would be.