Software Development: maintenance vs. hardcore coding

M

Matt

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

Sudsy

Matt said:
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 think it's just a different set of skills you have to use. With
maintenance programming, you've got to figure out what the original
author(s) were doing. You then have to incorporate the necessary
modification. You still have to know the language.
Writing apps from the ground up is challenging since you have to
utilize your design skills. You should also be aware of the "best"
approaches as proven in the real world.
I'd rather start fresh than have to maintain...
YMMV
 
R

Robert B.

Sudsy said:
I think it's just a different set of skills you have to use. With
maintenance programming, you've got to figure out what the original
author(s) were doing. You then have to incorporate the necessary
modification. You still have to know the language.
Writing apps from the ground up is challenging since you have to
utilize your design skills. You should also be aware of the "best"
approaches as proven in the real world.
I'd rather start fresh than have to maintain...
YMMV

Can't agree more with Sudsy. But also bear this in mind as an extension of
what he said. Maintenance and new development DO require different skill
sets. The thing is that few programmers are really good at both
disciplines. Unfortunately, management tends to look down on maintenance
programming which is a shame because, in many ways, their job is not only
harder, but more important! And I say this as someone who's very good at
design and new development.
 
R

Roedy Green

My conclusion is
hardcore coding really requires programming skills, but not necessary
ture in code mainteance.

I find writing code from scratch much easier. It is only me and the
computer, rather me and some "incompetent" programmer who did
everything possible to hide his intentions. See
http://mindprod.com/jgloss/unmain.html


On the other hand, when you are just starting out, it is much easier
to modify a program that works, especially a well-documented one, than
to start totally from scratch. You can get away with temporarily not
understanding bits of it.

When I post code on my website, I intend it to be used this way.
 
R

Roedy Green

And I say this as someone who's very good at
design and new development.

The best judges of who are the good development programmers are those
who have to maintain their code. The guys who got the job done fastest
and bug free are not necessarily the best. Over the life of a
project, a company spends 10 times on maintenance what they spent
originally writing it. Yet we still have the development tail wagging
the maintenance dog. Part of the problem is the low social status of
maintenance programmers. I do it all myself, so I am more attuned to
the plight of the maintenance programmer than most.

I am quite annoyed with Sun for again and again failing to consider
the needs of maintenance programmers.
 
S

Stephen Kellett

Roedy Green said:
I am quite annoyed with Sun for again and again failing to consider
the needs of maintenance programmers.

For sure. The lack of #ifdef (or equivalent) in both Java and C# is a
real pain. Makes some things that are trivial in C++ a real mess in
Java. I have a real need for this facility (in only a few places), but
the need is real. The only solution I have is commenting the code
heavily and then modifying the code as appropriate for my customer
depending on which build they are getting. Its truly awful, and should
be unnecessary.

Amazing that Microsoft made the same blunder with C# when you could see
this problem with Java and they had several years to identify this need.

Stephen
 
L

Larry Barowski

Matt said:
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.

Maybe that time doing maintenance has changed the way you code,
and you are now writing maintainable code, which takes much longer
than "hey, it works doesn't it?" code.
 
R

Robert B.

Roedy Green said:
The best judges of who are the good development programmers are those
who have to maintain their code. The guys who got the job done fastest
and bug free are not necessarily the best. Over the life of a
project, a company spends 10 times on maintenance what they spent
originally writing it. Yet we still have the development tail wagging
the maintenance dog. Part of the problem is the low social status of
maintenance programmers. I do it all myself, so I am more attuned to
the plight of the maintenance programmer than most.

I am quite annoyed with Sun for again and again failing to consider
the needs of maintenance programmers.

Every designer, no matter what they're working on, should consider
maintenance. I think that's what separates a good "scratch" developer from
the crowd. I was a Chevy person almost from the womb, but every time I gave
my 350 V8 a tune up, I wanted to shoot the designers for putting the back 2
plugs under the firewall. They did it on a V6 I owned and then had to put a
6 inch stalk on the fan shaft to get it closer to the radiator! And as far
as I can tell, they're still putting plugs back there. The other big thing
that separates good scratch developers is the ability to see beyond the
project, the enhancements that are bigger than maintenance. Where is the
app going to be in the future? How does it fit into the corp picture.
Without that vision, it's pretty easy to code yourself into a corner from
the standpoint of future enhancements. And it's been my experience that
foresight like that is sadly missing or put on the shelf in favor of "really
slick code".
 
R

Roedy Green

Amazing that Microsoft made the same blunder with C# when you could see
this problem with Java and they had several years to identify this need.

On the other paw, we have seen how easy it is to abuse the
preprocessor. I did an entire section on how to use the preprocessor
to write unmaintainable code in http://mindprod.com/jgloss/unmain.html

Perhaps by forcing people into ad hoc solutions, they stop people from
using preprocessing except where absolutely necessary.
 
M

Michael Borgwardt

Stephen said:
For sure. The lack of #ifdef (or equivalent) in both Java and C# is a
real pain. Makes some things that are trivial in C++ a real mess in
Java. I have a real need for this facility (in only a few places), but
the need is real. The only solution I have is commenting the code
heavily and then modifying the code as appropriate for my customer
depending on which build they are getting.

WTF you're talking about?

public static final boolean DEF_FOO = true;

..
..
..

if(DEF_FOO)
{
doFooStuff();
}
 
G

Guest

Stephen said:
For sure. The lack of #ifdef (or equivalent) in both Java and C# is a
real pain. Makes some things that are trivial in C++ a real mess in
Java. I have a real need for this facility (in only a few places), but
the need is real. The only solution I have is commenting the code
heavily and then modifying the code as appropriate for my customer
depending on which build they are getting. Its truly awful, and should
be unnecessary.

Amazing that Microsoft made the same blunder with C# when you could see
this problem with Java and they had several years to identify this need.

In C#

#define BLA_BLA_BLA
...
#if BLA_BLA_BLA
...
#else
...
#endif

In Java:

public static final boolean BLA_BLA_BLA = true;
...
if(BLA_BLA_BLA) {
...
} else {
...
}

- Dario
 
S

Stephen Kellett

Roedy Green said:
On the other paw, we have seen how easy it is to abuse the
preprocessor. I did an entire section on how to use the preprocessor
to write unmaintainable code in http://mindprod.com/jgloss/unmain.html

Sure, its easy to abuse an electric wall plug. Its also easy to use
safely. Same for the pre-processor. They should stop trying to make
these languages "safer" when the results actively get in the way of
software maintenance issues.

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?
Perhaps by forcing people into ad hoc solutions, they stop people from
using preprocessing except where absolutely necessary.

But the adhoc solution is worse! - editing the code each time.

Stpehen
 
S

Stephen Kellett

Michael Borgwardt said:
WTF you're talking about?

No need to swear. You should think more carefully about what the #ifdef
is trying to do.
public static final boolean DEF_FOO = true;

Wrong solution. The code doesn't compile. Thats what the #ifdef is for.
Removing the non-compiling code for this compile. With a different
version of Java it will compile. Not all code written for Java 2 will
compile for earlier versions of Java. This is a customer requirement I
have.

There is a really clumsy workaround. Write some class objects that
expose interfaces which are empty for one version of Java and
implemented for another version of Java and then put the appropriate
class files in each project. However if you saw where in the code this
has to go, you'll know why you wouldn't want to do this.

Like I wrote above, there is a very real need for #ifdef functionality,
just as there is in C++. If we had the ifdef we could have one project,
one source base and just compile a different version of the project. As
it is we need to either
1) Edit the source code, with specific comments telling you what to
edit. We may write a tool to automate the editing to prevent human
error.
2) Create multiple projects with different source files, some of which
are used in one environment and some in another.

Currently we use (1) because we don't want to have to go down (2) as
there are problems with this. The fact we are considering writing a tool
to do (1) indicates how badly we dislike (2).

Stephen
 
G

Guest

Stephen said:
No need to swear. You should think more carefully about what the #ifdef
is trying to do.


Wrong solution. The code doesn't compile. Thats what the #ifdef is for.
Removing the non-compiling code for this compile. With a different
version of Java it will compile. Not all code written for Java 2 will
compile for earlier versions of Java. This is a customer requirement I
have.

There is a really clumsy workaround. Write some class objects that
expose interfaces which are empty for one version of Java and
implemented for another version of Java and then put the appropriate
class files in each project. However if you saw where in the code this
has to go, you'll know why you wouldn't want to do this.

I really not have understood why you cannot use of if(DEF_FOO) paradigm.
Like I wrote above, there is a very real need for #ifdef functionality,
just as there is in C++. If we had the ifdef we could have one project,
one source base and just compile a different version of the project.

In any case:
Who prevents you to write #ifdef in your Java sources
and pre-process your Java sources via a C pre-processor?

- Dario
 
S

Stephen Kellett

I really not have understood why you cannot use of if(DEF_FOO) paradigm.

Consider:

DEF_FOO == false for pre Java 2
DEF_FOO == true for Java 2

if (DEF_FOO)
{
// pre Java 2 only code here
}
else
{
// Java 2 only code here

// this code does not compile when compiled with an
// early Java compiler
}

My customer wants the same code to run with Java 2 and with pre Java 2
runtimes. I've tried your solution with the Symantec Cafe 3.0 compiler.
It won't compile the code (even though static analysis shows that it
will never execute the non-compiling code because of the if () clause
directing it to the pre-Java 2 code).

Another problem. Assuming a release mode compiler will optimize out the
none-executable portion, a debug mode compiler won't optimize, so you
still have the problem.
In any case:
Who prevents you to write #ifdef in your Java sources
and pre-process your Java sources via a C pre-processor?

Too much effort. Support should be part of the language. Maintenance
should be thought of at the language design stage.

Another problem with Java, which is a design and maintenance issue:

Lack of support for enumerations, unless thats been added for Java 2
(and I've missed it - which is possible, given that I mainly write C++).
Problem is the code I'm writing needs to be compilable with pre Java 2
compilers. So even if enumerations have finally been added to Java I
can't use them.

The clumsy, none-type-safe workaround is defining lots of public final
integer constants in your class. A slightly clumsier workaround is
defining lots of public final integer constants in their own class. Why
can't I just define them as an enumeration in whichever class I see fit?
The type safety restrictions are in force at compile time, the JVM would
still see these as integers and treat them as such.

What could be simpler than

enum enumerationName
{
enumValue1,
enumValue2,
enumValue3
};

Note, no need for public, final, static, integer or assignment of any
value (although the ability to do the latter may be useful in some
places).

compared to

class myEnumerationClass
{
public static final integer enumValue1 = 1;
public static final integer enumValue2 = 2;
public static final integer enumValue3 = 3;
};

and there is *still* no actual concept at the language level that these
three integers are part of the same enumeration. They are just integers
which can be assigned to any other integer. If they were enumerations
you'd be get a type safety error from the compiler if you tried to
assign them to a different enumeration type.

There is plenty of space in the Java instruction set for support of
this, if they wanted to handle enumerations as a special type. I don't
think they'd need to do that. It could all be handled at the compiler
level.

I fail to see how forcing clumsy representations of simple concepts
makes writing software easier or aids maintainability.

</aaah! endRant>

I think #ifdef and lack of enums annoy me more than anything else about
Java. Lack of enumerations really really annoys me. There is just no
excuse for a modern language, especially an object oriented one
supposedly promoting type safety, its like going back to assembly
language, where everything is integers.

Stephen
 
T

Tim Ward

Stephen Kellett said:
I think ... lack of enums annoy me more than anything else about
Java. Lack of enumerations really really annoys me. There is just no
excuse for a modern language, especially an object oriented one
supposedly promoting type safety, its like going back to assembly
language, where everything is integers.

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

The "correct" answer is to follow one of the (147 or so different) "enum
patterns" out there. Typically each involves writing about 27,364 lines of
code for each enum, which gets you back to type safety. Except that the
different patterns are religions, and the priests of one will tell you that
the others aren't "really type safe", or something. The only thing on which
they all agree is that the vast amounts of (expensive, error prone) code you
have to write, and debug, and the CPU overhead, are a "price worth paying"
for the "correct" decision to leave "unclean! unclean!" enums out of the
language. Or something. Without quite getting round to explaining why enums
were "unclean" in the first place.

'Spose I'd better copy your:

</aaah! endRant>
 
T

Tim Ward

Tim Ward said:
Without quite getting round to explaining why enums were "unclean" in the
first place.

Sorry, I should have explained that they do have an answer to this, which is
that enums in C aren't type safe. (These Java priests don't seem to have
noticed that enums in C++ are a bit different.)

Actually there *is* something wrong with enums in C++: you can switch on an
enum value, and the compiler won't tell you that the case labels are in fact
not values of the enum. But are the Java enum patterns any better? - yes of
course, you can't switch on them *at* *all*, so this problem doesn't arise,
so this is "better" isn't it.
 
C

Chris Smith

Stephen said:
Too much effort. Support should be part of the language. Maintenance
should be thought of at the language design stage.

This, really, comes down to a question of how badly you want
preprocessing. I agree that the C preprocessor is poorly suited for
Java -- particularly given that you'd have to be very careful to pass
proper options to prevent it from outputting debug helpers for the C
compiler. However, other preprocessors (especially m4, IMO) could be
far more suited, and even far more capable.

Another alternative, probably more commonly used in practice, is to use
ant and @TOKEN@. If you define a token to "//" for some set of builds,
then you can prefix conditional lines with that token to exclude the
line from those builds. This is, for example, how the PostgreSQL JDBC
driver is able to build for multiple versions of the JDBC API, which are
by and large not compatible across versions from the perspective of an
implementor.

Since very few people really build Java projects in the realy world by
invoking javac directly, I seriously doubt that you'd encounter great
difficulty incorporating these external tools into your build. Really
that would be no different from the C preprocessor, except that the C
and C++ languages are built to assume you'll use the preprocessor, and
act as an integrated build tool by invoking it for you in mant
circumstances.
Another problem with Java, which is a design and maintenance issue:

Lack of support for enumerations, unless thats been added for Java 2
(and I've missed it - which is possible, given that I mainly write C++).

It's being added for 1.5, which should be released some time this year.
Many people are in agreement with you that it's been too long in coming.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
C

Chris Smith

Tim said:
The "correct" answer is to follow one of the (147 or so different) "enum
patterns" out there. Typically each involves writing about 27,364 lines of
code for each enum, which gets you back to type safety. Except that the
different patterns are religions, and the priests of one will tell you that
the others aren't "really type safe", or something.

There are generally two enumeration patterns for Java (to be defunct in
1.5 with language-supported enumerations). They are use of int
constants, and use of references to a class with a private constructor.
They each have different advantages, but I seriously doubt anyone will
tell you that the former is type-safe, or that the latter is not.
There's not nearly so much confusion as you suggest. There's just an
easy way, and a hard (and more correct, but occasionally less convenient
in usage) way.
The only thing on which
they all agree is that the vast amounts of (expensive, error prone) code you
have to write, and debug, and the CPU overhead, are a "price worth paying"
for the "correct" decision to leave "unclean! unclean!" enums out of the
language. Or something.

I don't know who's saying this. Certainly not the many Java programmers
who asked Sun to add enums, nor Sun's Java team who decided to implement
them. Maybe you only talk to weirdos. :)

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,578
Members
45,052
Latest member
LucyCarper

Latest Threads

Top