Software Development: maintenance vs. hardcore coding

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

  1. Matt

    Roedy Green Guest

    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, Jun 28, 2004
    #21
    1. Advertisements

  2. Matt

    Roedy Green Guest

    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.
     
    Roedy Green, Jun 28, 2004
    #22
    1. Advertisements

  3. I suspected as much :)

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

    Stephen
     
    Stephen Kellett, Jun 28, 2004
    #23
  4. Matt

    Sam Guest


    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
     
    Sam, Jun 28, 2004
    #24
  5. Matt

    Roedy Green Guest

    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
     
    Roedy Green, Jun 28, 2004
    #25
  6. 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
     
    Stephen Kellett, Jun 28, 2004
    #26
  7. Matt

    Tim Ward Guest

    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).
     
    Tim Ward, Jun 29, 2004
    #27
  8. Matt

    Roedy Green Guest

    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.
     
    Roedy Green, Jun 29, 2004
    #28
  9. 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
     
    Stephen Kellett, Jun 29, 2004
    #29
  10. Matt

    Roedy Green Guest

    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.
     
    Roedy Green, Jun 29, 2004
    #30
    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.