A Trend Towards Lower Software Maintenance Budgets?

Discussion in 'C Programming' started by editormt, Oct 30, 2007.

  1. editormt

    editormt Guest

    Software maintenance is an important part of the software development
    activity, but it is also the less discussed. A recent poll seems to
    show that the part of maintenance in software development budget is
    going down. Why?

    Question: what percentage of your software development budget is
    devoted to maintenance. Maintenance is defined as process of
    correcting, enhancing and optimising deployed software.

    25% or less of the budget ...........37%
    26% to 50% of the budget ............27%
    51% to 75% of the budget ............24%
    more than 75% of the budget .........12%

    Number of participants: 433

    The annual maintenance costs in the US are estimated at over $ 70
    billion. According to the different studies produced in the last
    century, maintenance should cost between 66% and 90% of the total life
    cycle costs. We can see in our survey that the majority of the
    participants estimate their maintenance budget below the 50%
    threshold. If we accept that these numbers are representative of a
    modified situation, many hypothesis can be made to explain it.

    Go to http://www.methodsandtools.com/dynpoll/oldpoll.php?Maintenance
    to see these reasons and get more resources on software maintenance.
     
    editormt, Oct 30, 2007
    #1
    1. Advertisements

  2. editormt

    CBFalconer Guest

    Because in c.l.c you are accessing the better programmers, who tend
    to write perfect software, which anticipate all future
    requirements, and have no bugs. Next question.
     
    CBFalconer, Oct 30, 2007
    #2
    1. Advertisements

  3. editormt

    jacob navia Guest

    Specially when the salary of programmers goes down and down and down.
     
    jacob navia, Oct 30, 2007
    #3
  4. Extreme programming. It has been recognised that it is easier to write
    things from scratch than to try to endlessly patch old code.
     
    Malcolm McLean, Oct 30, 2007
    #4
  5. editormt

    santosh Guest

    Interesting. Over here it's going up and up and up, at least for a
    subset of "programmers".
     
    santosh, Oct 31, 2007
    #5
  6. editormt

    Flash Gordon Guest

    Malcolm McLean wrote, On 30/10/07 22:58:
    That is a vast oversimplification at the very least. I have 50,000 lines
    of code, is it easier to change 10 lines of code to fix an issue or
    rewrite the program? I have a 5 line program, is it easier to patch it
    for a massive change or rewrite it?
     
    Flash Gordon, Oct 31, 2007
    #6
  7. editormt

    Chris Dollin Guest

    Granting that ...
    He said /endlessly/. One ten-line fix might be cost-effective. A thousand
    might not be.

    It's all choices of tradeoffs; one needs to know the business value and the
    expected costs.

    (I don't know what Malcolm meant when he said "extreme programming", but I
    do know that the term as I understand it doesn't mean (only) "rewrite, don't
    modify". If you /have/ a Whole Bunch Of Existing Code, how you deal with
    it will Depend On Many Things, whether you're using XP or not.)
     
    Chris Dollin, Oct 31, 2007
    #7
  8. editormt

    Flash Gordon Guest

    Chris Dollin wrote, On 31/10/07 10:00:
    OK, so you agree with the main point of my post :)
    Yes, which was my point. Sometimes code needs to be scrapped and
    rewritten, sometimes it needs to be modified. This applies at all scales
    (yes, I've been involved in scrapping and rewriting what after the
    rewrite was about 50000 LOC). So blanket advice to scrap and rewrite is
    bad advice just as blanket advice to always modify what you have is bad.
     
    Flash Gordon, Oct 31, 2007
    #8
  9. Our particular development cycle usually involves writing something
    in a prototyping language (e.g., MATLAB, maple, Mathematica, IDL)
    and hacking on it endlessly for a few years, changing our mind about
    what it is supposed to do several times a day. This is the exploratory
    research phase, where we often do not know if something is possible
    and we often do not know if we have reached the "right" answer.
    The sort of code where a bug might happen to produce a better answer
    than what we thought we were coding, leaving us to scratch our heads
    and re-re-analyze to improve our techniques. Naturally, with so many
    changes in purpose and technique going on, the end result is often
    a coding mess.

    Once we have figured out what works (and what doesn't) and have
    a functional implementation, it's time to hand it over to another
    group that extracts the good parts and rewrites them cleanly and
    efficiently in C++ or C as part of our integrated research framework.

    It would not be unfair to say that at that point we are throwing
    out several 10's of kLOC and several person-years of coding, to be
    rewritten into a completely different form. This isn't a waste of
    time: it is the point that seperates the "Research" from the
    "Development".
     
    Walter Roberson, Oct 31, 2007
    #9
  10. The word you're looking for is 'postulated'.
    And anyway Extreme Programming is just a high-falutin Web 2.0ism for
    what most of us have done for decades, ie short-cycle continuous
    development to cope with rapidly changing (or inadequately defined!)
    business requirements, and a demand for rapid delivery of /something,
    anything/....
    IMHO it is /sometimes/ easier to do this, and /sometimes/ more
    complicated.

    eg If I have a ten-million line accounting programme, I'm not going to
    rewrite it from scratch to handle the change from two to zero decimals
    for Icelandic Krona.

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Oct 31, 2007
    #10
  11. Define "cost effective". Within this year's budget?
    Absolutely. Something that often escapes the XP zealots, just as the
    virtue of rapid development cycles often escapes the plan-it-to-death
    zealots.

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Oct 31, 2007
    #11
  12. editormt

    Ian Collins Guest

    That's simply not true, XP predates whatever today's definition of Web 2
    is by many years and it encompasses a lot more than short-cycle
    continuous development.
     
    Ian Collins, Nov 1, 2007
    #12
  13. editormt

    Chris Dollin Guest

    Situation-dependant. How could it not be?
    Um ... XP's planning game is /about/ business value and costs. Those must
    have been some interesting zealots. I suppose that's how we recognise
    zealots of whatever stripe ...
     
    Chris Dollin, Nov 1, 2007
    #13
  14. I wish... I've met some folk who regard XP as about shipping code as
    fast as possible, scoring points over the plodders still using trad
    methods, and then clearing out quick before the maintenance costs kick
    in.
    indeed !
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Nov 1, 2007
    #14
  15. XP as nametag in popular use is very recent. Sure, Kent dreamed it up
    in the mid nineties, but it wasn't popularised till much later, and
    the principles which XP embodies have been around for many decades.
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Nov 1, 2007
    #15
  16. editormt

    Chris Dollin Guest

    Well, it is.
    There is no method, however good, that can't be misused or abused by
    sufficiently determined/ignorant/naive/malicious persons. I think the
    "clearing out quick" is pretty obviously not in accordance with XP
    as I have seen it expressed in the core books & mailing list (although
    one wonders what the contractual situation was).

    I think I've done enough atopical writing for the moment.
     
    Chris Dollin, Nov 1, 2007
    #16
  17. editormt

    Ian Collins Guest

    Then they are using then name without applying the practices. Such
    people give whatever they claim to be doing a bad name. Don't judge
    something until you have seen how it should be done.
     
    Ian Collins, Nov 1, 2007
    #17
  18. editormt

    Ian Collins Guest

    It was polularised (at least here) in the late nineties, I adopted it
    for my shop in 2000.

    The principles of XP have been around for ages, but Kent's light bulb
    moment was pull them all together to build a people centric development
    process.
     
    Ian Collins, Nov 1, 2007
    #18
  19. editormt

    Flash Gordon Guest

    Walter Roberson wrote, On 31/10/07 19:33:
    None of which contradicts what I said. I'm sure you do not go throwing
    away 10's of kLOC on every change prior to passing it over for the
    re-implementation, and I'm sure it does not get thrown away every time
    it needs a change after that point. I would also be surprised if each
    time you need to change a module within that code base you threw it
    away, or each time you changed a function within the module.

    Throw away code when it needs throwing away, modify it when it needs
    modifying.
     
    Flash Gordon, Nov 1, 2007
    #19
  20. Generally it is reckoned that you need to start over if you end up modifying
    more than 20%. That's a much lower threshold than was previously accepted.

    XP tends to look at existing practises, and instead of saying "here's an
    inefficiency we must stamp out" it says "why is this practise current?".
    Then it formalises it by incorporating it into the method. So partly it is
    just political, things we've always done - had to do - are now part of "the
    method" so there's no time wasted apologising for them or disguising them.
    Rewriting code is a case in point. It is given a fancy name - "refactoring"
    to get it past the men in suits.
     
    Malcolm McLean, Nov 1, 2007
    #20
    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.