A Trend Towards Lower Software Maintenance Budgets?

[editormt]

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.

 

[CBFalconer]

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?

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.

 

[jacob navia]

Extreme programming. It has been recognised that it is easier to write
things from scratch than to try to endlessly patch old code.

Specially when the salary of programmers goes down and down and down.

 

[Malcolm McLean]

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?

Extreme programming. It has been recognised that it is easier to write
things from scratch than to try to endlessly patch old code.

 

[santosh]

Specially when the salary of programmers goes down and down and down.

Interesting. Over here it's going up and up and up, at least for a
subset of "programmers".

 

[Flash Gordon]

Malcolm McLean wrote, On 30/10/07 22:58:

Extreme programming. It has been recognised that it is easier to write
things from scratch than to try to endlessly patch old code.

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?

 

[Chris Dollin]

Malcolm McLean wrote, On 30/10/07 22:58:

That is a vast oversimplification at the very least.

Granting that ...

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?

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

 

[Flash Gordon]

Chris Dollin wrote, On 31/10/07 10:00:

Granting that ...

OK, so you agree with the main point of my post

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

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.

 

[Walter Roberson]

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.

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

 

[Mark McIntyre]

Extreme programming. It has been recognised

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

that it is easier to write
things from scratch than to try to endlessly patch old code.

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]

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

Define "cost effective". Within this year's budget?

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

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

 

[Ian Collins]

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

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.

 

[Chris Dollin]

Define "cost effective". Within this year's budget?

Situation-dependant. How could it not be?

Absolutely. Something that often escapes the XP zealots,

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

 

[Mark McIntyre]

Um ... XP's planning game is /about/ business value and costs.

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.

Those must
have been some interesting zealots. I suppose that's how we recognise
zealots of whatever stripe ...

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]

XP predates whatever today's definition of Web 2
is by many years and it encompasses a lot more than short-cycle
continuous development.

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

 

[Chris Dollin]

I wish...

Well, it is.

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.

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.

 

[Ian Collins]

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.

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]

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.

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.

 

[Flash Gordon]

Walter Roberson wrote, On 31/10/07 19:33:

Our particular development cycle usually involves writing something
in a prototyping language (e.g., MATLAB, maple, Mathematica, IDL)

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

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.

 

[Malcolm McLean]

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.

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.