Software Development: maintenance vs. hardcore coding

Discussion in 'Java' started by Matt, Jun 26, 2004.

  1. Matt

    Matt Guest

    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?
    Matt, Jun 26, 2004
    1. Advertisements

  2. Matt

    Sudsy Guest

    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...
    Sudsy, Jun 26, 2004
    1. Advertisements

  3. Matt

    Robert B. Guest

    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.
    Robert B., Jun 27, 2004
  4. Matt

    Roedy Green Guest

    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

    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.
    Roedy Green, Jun 27, 2004
  5. Matt

    Roedy Green Guest

    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.
    Roedy Green, Jun 27, 2004
  6. 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 Kellett, Jun 27, 2004
  7. 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.
    Larry Barowski, Jun 27, 2004
  8. Matt

    Robert B. Guest

    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".
    Robert B., Jun 28, 2004
  9. Matt

    Roedy Green Guest

    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

    Perhaps by forcing people into ad hoc solutions, they stop people from
    using preprocessing except where absolutely necessary.
    Roedy Green, Jun 28, 2004
  10. WTF you're talking about?

    public static final boolean DEF_FOO = true;


    Michael Borgwardt, Jun 28, 2004
  11. Matt

    Guest Guest

    In C#

    #define BLA_BLA_BLA
    #if BLA_BLA_BLA

    In Java:

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

    - Dario
    Guest, Jun 28, 2004
  12. 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?
    But the adhoc solution is worse! - editing the code each time.

    Stephen Kellett, Jun 28, 2004
  13. 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

    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
    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 Kellett, Jun 28, 2004
  14. Oh good. My mistake regarding C#.
    Incorrect solution. See my reply to this in a different posting.

    Stephen Kellett, Jun 28, 2004
  15. Matt

    Guest Guest

    I really not have understood why you cannot use of if(DEF_FOO) paradigm.
    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
    Guest, Jun 28, 2004
  16. I really not have understood why you cannot use of if(DEF_FOO) paradigm.


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

    if (DEF_FOO)
    // pre Java 2 only code here
    // 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.
    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

    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

    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

    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 Kellett, Jun 28, 2004
  17. Matt

    Tim Ward Guest

    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>
    Tim Ward, Jun 28, 2004
  18. Matt

    Tim Ward Guest

    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.
    Tim Ward, Jun 28, 2004
  19. Matt

    Chris Smith Guest

    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 @[email protected] 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

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

    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Jun 28, 2004
  20. Matt

    Chris Smith Guest

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

    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Jun 28, 2004
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.