469,331 Members | 4,122 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,331 developers. It's quick & easy.

A Trend Towards Lower Software Maintenance Budgets?

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/dynpo...hp?Maintenance
to see these reasons and get more resources on software maintenance.

Oct 30 '07 #1
47 1478
editormt wrote:
>
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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Oct 30 '07 #2

"editormt" <ed****@methodsandtools.comwrote in message
news:11*********************@o3g2000hsb.googlegrou ps.com...
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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 30 '07 #3
Malcolm McLean wrote:
>
"editormt" <ed****@methodsandtools.comwrote in message
news:11*********************@o3g2000hsb.googlegrou ps.com...
>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.
Specially when the salary of programmers goes down and down and down.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 30 '07 #4
jacob navia wrote:
Malcolm McLean wrote:
>>
"editormt" <ed****@methodsandtools.comwrote in message
news:11*********************@o3g2000hsb.googlegro ups.com...
>>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.

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

Oct 31 '07 #5
Malcolm McLean wrote, On 30/10/07 22:58:
>
"editormt" <ed****@methodsandtools.comwrote in message
news:11*********************@o3g2000hsb.googlegrou ps.com...
>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.
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 '07 #6
Flash Gordon wrote:
Malcolm McLean wrote, On 30/10/07 22:58:
>>
"editormt" <ed****@methodsandtools.comwrote in message
news:11*********************@o3g2000hsb.googlegro ups.com...
>>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.

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

--
Chris "not /that/ XP, the /real/ XP" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Oct 31 '07 #7
Chris Dollin wrote, On 31/10/07 10:00:
Flash Gordon wrote:
>Malcolm McLean wrote, On 30/10/07 22:58:
>>"editormt" <ed****@methodsandtools.comwrote in message
news:11*********************@o3g2000hsb.googlegr oups.com...
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.
That is a vast oversimplification at the very least.

Granting that ...
OK, so you agree with the main point of my post :-)
>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.)
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 '07 #8
In article <bu************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:
>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".
--
So you found your solution
What will be your last contribution?
-- Supertramp (Fool's Overture)
Oct 31 '07 #9
On Tue, 30 Oct 2007 22:58:53 -0000, in comp.lang.c , "Malcolm McLean"
<re*******@btinternet.comwrote:
>
"editormt" <ed****@methodsandtools.comwrote in message
news:11*********************@o3g2000hsb.googlegro ups.com...
>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
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
Oct 31 '07 #10
On Wed, 31 Oct 2007 10:00:43 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>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
Oct 31 '07 #11
Mark McIntyre wrote:
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.

--
Ian Collins.
Nov 1 '07 #12
Mark McIntyre wrote:
On Wed, 31 Oct 2007 10:00:43 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>>He said /endlessly/. One ten-line fix might be cost-effective. A thousand
might not be.

Define "cost effective". Within this year's budget?
Situation-dependant. How could it not be?
>>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,
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 "zealously against zealotry" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Nov 1 '07 #13
On Thu, 01 Nov 2007 08:48:27 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>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
Nov 1 '07 #14
On Thu, 01 Nov 2007 14:23:11 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>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
Nov 1 '07 #15
Mark McIntyre wrote:
On Thu, 01 Nov 2007 08:48:27 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>>Um ... XP's planning game is /about/ business value and costs.

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.

--
Chris "someone ask an interesting C question" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Nov 1 '07 #16
Mark McIntyre wrote:
On Thu, 01 Nov 2007 08:48:27 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>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.
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 '07 #17
Mark McIntyre wrote:
On Thu, 01 Nov 2007 14:23:11 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>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.
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 '07 #18
Walter Roberson wrote, On 31/10/07 19:33:
In article <bu************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:
>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)
<snip>
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.
--
Flash Gordon
Nov 1 '07 #19

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>
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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 1 '07 #20
"Malcolm McLean" <re*******@btinternet.comwrites:
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>>
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.
Can you cite a report stating that? It depends very much on the
application structure and how it was coded.

It could well be that a suite of modules all bridge into the rest of the
application through a well defined API. These modules could be, say,
50%, of the entire app. But rewriting these doesn't mean touching the
rest.
>
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.
Nov 1 '07 #21

"Richard" <rg****@gmail.comwrote in message
news:u9************@news.individual.net...
"Malcolm McLean" <re*******@btinternet.comwrites:
>"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>>>
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.

Can you cite a report stating that? It depends very much on the
application structure and how it was coded.

It could well be that a suite of modules all bridge into the rest of the
application through a well defined API. These modules could be, say,
50%, of the entire app. But rewriting these doesn't mean touching the
rest.
That's part of the skill. Knowing where the boundaries are so you know what
to "refactor".
The 20% figure is bandied about quite a bit. However it is not very
scientific. In practise "refactoring" doesn't usually keep the external
interfaces the same, so in fact it is not distinguished from "rewriting".
The insight is that generally it is cheaper to scrap code and start over
than to try to modify.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 1 '07 #22
Richard wrote:
"Malcolm McLean" <re*******@btinternet.comwrites:
....
>The snags with a lot of formal methods are mind-crashingly
simple. Instead of wrting correct code first time, we write a correct
design first time, and then get a low skilled person to code it up.

low skilled people can not code anything up in C.
Sure they can. Low skilled people have done most of the coding for the
programs I'm responsible for. Highly skilled people do the detailed
design, participate in code reviews, and sign off on the test results. I
won't claim this was ideal; I'd love to have a team of people who were
all at my own skill level or higher. However, we do produce working code
of acceptable quality, and we cost the company a whole lot less than my
ideal team would cost. I doubt that my company is the only one that's
chosen this trade-off, regardless of whether or not it was a wise one.
Nov 2 '07 #23
James Kuyper <ja*********@verizon.netwrites:
Richard wrote:
>"Malcolm McLean" <re*******@btinternet.comwrites:
...
>>The snags with a lot of formal methods are mind-crashingly
simple. Instead of wrting correct code first time, we write a correct
design first time, and then get a low skilled person to code it
up.

low skilled people can not code anything up in C.

Sure they can. Low skilled people have done most of the coding for the
programs I'm responsible for. Highly skilled people do the detailed
design, participate in code reviews, and sign off on the test
Highly skilled people code too. Low skilled people will turn out poor
code.
results. I won't claim this was ideal; I'd love to have a team of
people who were all at my own skill level or higher. However, we do
Is higher possible? :-;
produce working code of acceptable quality, and we cost the company a
whole lot less than my ideal team would cost. I doubt that my company
is the only one that's chosen this trade-off, regardless of whether or
not it was a wise one.
Low skilled people can produce code. Yes. When I said "anything" above I
was being a little too extreme I suppose.
Nov 2 '07 #24
Richard wrote:
James Kuyper <ja*********@verizon.netwrites:
....
>Sure they can. Low skilled people have done most of the coding for the
programs I'm responsible for. Highly skilled people do the detailed
design, participate in code reviews, and sign off on the test

Highly skilled people code too.
Yes, that too. There aren't enough people in my group for anyone to be a
non-coding specialist.
Low skilled people will turn out poor code.
Yes, but with supervision that poor code can be caught and corrected.
>results. I won't claim this was ideal; I'd love to have a team of
people who were all at my own skill level or higher. However, we do

Is higher possible? :-;
Thanks for the vote of confidence!
Nov 2 '07 #25
Malcolm McLean wrote:
>>
That's part of the skill. Knowing where the boundaries are so you know
what to "refactor".
The 20% figure is bandied about quite a bit. However it is not very
scientific. In practise "refactoring" doesn't usually keep the external
interfaces the same, so in fact it is not distinguished from
"rewriting". The insight is that generally it is cheaper to scrap code
and start over than to try to modify.
Nonsense, refactoring does not change the behaviour of the code, which
includes its public interfaces. The term is abused all to often when
that is being done is a rewrite.

--
Ian Collins.
Nov 2 '07 #26
Malcolm McLean wrote:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>>
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?".
No it does not.
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.
You should read a decent book on refactoring, you obviously don't know
what you are talking about.

--
Ian Collins.
Nov 2 '07 #27
Ian Collins <ia******@hotmail.comwrote:
people centric development process.
Bucket, please.

Richard
Nov 2 '07 #28
Malcolm McLean wrote:
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.
Refactoring isn't just "rewriting code". It's making meaning-preserving (in
context) transformations to the code to improve the design (where "improve"
is along whatever metrics are important in the context), often followed by
value-adding changes to the code that are enabled or assisted by the
refactoring.

Refactoring also implies ways of showing that the refactoring hasn't broken
the code; by implication (the refactoring is performed by a reliable tool
that doesn't make silly mistakes) or by testing (running the relevant [1]
test suites, doing manual testing if there's no other way).

Claiming that refactorings are just the rewritings we've always done -- which
it my reading of Malcolm's paragraph above -- seems to me to be a dreadful
misrepresentation.

[1] Which is all of them, eventually.

--
Chris "see Martin Fowler's book for extended (but not C) discussion" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Nov 2 '07 #29
Ian Collins wrote, On 02/11/07 05:45:
Malcolm McLean wrote:
>That's part of the skill. Knowing where the boundaries are so you know
what to "refactor".
The 20% figure is bandied about quite a bit. However it is not very
scientific. In practise "refactoring" doesn't usually keep the external
interfaces the same, so in fact it is not distinguished from
"rewriting". The insight is that generally it is cheaper to scrap code
and start over than to try to modify.
Well, at least you have gone from a blanket scrap and rewrite to
"generally", i.e. not always.
Nonsense, refactoring does not change the behaviour of the code, which
includes its public interfaces. The term is abused all to often when
that is being done is a rewrite.
Also refactoring in at least some cases does not involve rewriting the
code being refactored. On one occasion when I was refactoring a project
I had to rename some functions, move a few bits about, and change under
1% of the code to go from what I considered to be a terrible structure
to a really nice structure.

Re-factoring can be as simple as pulling a block of code out of one
function in to a separate function and calling it from the first
function. Or it can involve a lot more change and major rewrites.

Finally, there are some problem domains where if you know the domain
well you can predict extremely accurately where requirements will change
over time and in general what sort of changes will occur and design your
SW specifically to allow those changes. Sometimes you will be wrong, and
sometimes it is simply not possible to guess what is likely, but in some
domains it is.
--
Flash Gordon
Who rarely thinks that one solution fits all situations
Nov 2 '07 #30
On Fri, 02 Nov 2007 07:26:41 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>Ian Collins <ia******@hotmail.comwrote:
>people centric development process.

Bucket, please.
Here, use the one I just used after reading that hideous
managementspeak .. :-)
--
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
Nov 2 '07 #31
On Fri, 02 Nov 2007 07:33:13 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>Don't judge
something until you have seen how it should be done.
Ive never said I was judging it. I've been using the technique since
when people thought digital watches were cool. What I'm judging is
the ludicrous name. There's nothing extreme about it, and adding
hideous acronym-ready names to methodologies makes me reach for the
pointed stick.

Also lets remember there ain't no silver bullet, and zealots of all
sorts must be burned at the stake, ere they infect everyone with their
heretical ways, their filthy fingers are not fit to sully the
keyboards of the righteous, froth, rant...

I'll get me coat.
--
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
Nov 2 '07 #32
"Ian Collins" <ia******@hotmail.comwrote in message
Malcolm McLean wrote:
>>>
That's part of the skill. Knowing where the boundaries are so you know
what to "refactor".
The 20% figure is bandied about quite a bit. However it is not very
scientific. In practise "refactoring" doesn't usually keep the external
interfaces the same, so in fact it is not distinguished from
"rewriting". The insight is that generally it is cheaper to scrap code
and start over than to try to modify.
Nonsense, refactoring does not change the behaviour of the code, which
includes its public interfaces. The term is abused all to often when
that is being done is a rewrite.
I've heard enough people abuse the term to realise that it is largely a
euphemism for rewriting. Normally code is rewritten because it is buggy, or
because someone wants to extend functionality. However there is a strong
case for rewriting working code that is a mess. The other reason is
optimisation. That's where the problems come in. Very commonly you optimise
by saving intermediate calculations so they don't need to be repeated. So
you cannot actually keep the public interface the same, although the
underlying functionality is the same.

However it is a good thing to have a buzzy term for "rewrite". "Rewrite"
carries too many negative connotations. Appearances matter. It shouldn't be
that way, but it is.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 3 '07 #33
Malcolm McLean wrote:
>
However it is a good thing to have a buzzy term for "rewrite". "Rewrite"
carries too many negative connotations. Appearances matter. It shouldn't
be that way, but it is.
No, you should call a spade a spade. If you have to hide behind buzz
words, either your organisation and/or process is broken.

--
Ian Collins.
Nov 3 '07 #34
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
.... snip ...
>
>Nonsense, refactoring does not change the behaviour of the code,
which includes its public interfaces. The term is abused all to
often when that is being done is a rewrite.

I've heard enough people abuse the term to realise that it is
largely a euphemism for rewriting. Normally code is rewritten
because it is buggy, or because someone wants to extend
functionality. However there is a strong case for rewriting
working code that is a mess. The other reason is optimisation.
That's where the problems come in. Very commonly you optimise
by saving intermediate calculations so they don't need to be
repeated. So you cannot actually keep the public interface the
same, although the underlying functionality is the same.

However it is a good thing to have a buzzy term for "rewrite".
"Rewrite" carries too many negative connotations. Appearances
matter. It shouldn't be that way, but it is.
I have been known to 'rewrite' the code just to familiarize myself
with the original. In this case the first rewrite consists of
proper (to me) formatting.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Nov 3 '07 #35
On Sat, 03 Nov 2007 20:33:27 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>Malcolm McLean wrote:
>>
However it is a good thing to have a buzzy term for "rewrite". "Rewrite"
carries too many negative connotations. Appearances matter. It shouldn't
be that way, but it is.
No, you should call a spade a spade. If you have to hide behind buzz
words, either your organisation and/or process is broken.
Welcome to Fantasy island. :-)

Show me a senior manager who prefers "rewrite" to "refactor", or
"sack" to "downsize" for that matter.
--
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
Nov 4 '07 #36
Mark McIntyre wrote:
On Sat, 03 Nov 2007 20:33:27 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>Malcolm McLean wrote:
>>However it is a good thing to have a buzzy term for "rewrite". "Rewrite"
carries too many negative connotations. Appearances matter. It shouldn't
be that way, but it is.
No, you should call a spade a spade. If you have to hide behind buzz
words, either your organisation and/or process is broken.

Welcome to Fantasy island. :-)

Show me a senior manager who prefers "rewrite" to "refactor", or
"sack" to "downsize" for that matter.
Me?

--
Ian Collins.
Nov 4 '07 #37
"Ian Collins" <ia******@hotmail.comwrote in message
Mark McIntyre wrote:
>>
Show me a senior manager who prefers "rewrite" to "refactor", or
"sack" to "downsize" for that matter.

Me?
Social manipulation works.
Most people, if you do a straw poll, will say that what you call the beer,
soap powder, or whatever has no impact on their purchasing decison. However
manufacturers spend large sums of money on brand management.

Similarly if you ask a manager, upfront, "do you prefer people to speak
honestly or do you like buzzwords?", they will usually say that they believe
in plain English. Sometimes it is true, but generally the situation is that,
like the consumers, they have little insight into their own behaviour.
XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to force
a alien mould onto the programmer. There's more it than that, of course, but
the marketing aspect shouldn't be downplayed.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 4 '07 #38
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
>Mark McIntyre wrote:
>>>
Show me a senior manager who prefers "rewrite" to "refactor", or
"sack" to "downsize" for that matter.

Me?
Social manipulation works.
Most people, if you do a straw poll, will say that what you call the
beer, soap powder, or whatever has no impact on their purchasing
decison. However manufacturers spend large sums of money on brand
management.

Similarly if you ask a manager, upfront, "do you prefer people to speak
honestly or do you like buzzwords?", they will usually say that they
believe in plain English. Sometimes it is true, but generally the
situation is that, like the consumers, they have little insight into
their own behaviour.
That's one way that Kiwis differ from us Poms, a lot more straight
talking goes on down here!
XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to
force a alien mould onto the programmer. There's more it than that, of
course, but the marketing aspect shouldn't be downplayed.
There's a lot more to it than that.

--
Ian Collins.
Nov 5 '07 #39
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
>Malcolm McLean wrote:
>>>>
That's part of the skill. Knowing where the boundaries are so you know
what to "refactor".
The 20% figure is bandied about quite a bit. However it is not very
scientific. In practise "refactoring" doesn't usually keep the external
interfaces the same, so in fact it is not distinguished from
"rewriting". The insight is that generally it is cheaper to scrap code
and start over than to try to modify.
Nonsense, refactoring does not change the behaviour of the code, which
includes its public interfaces. The term is abused all to often when
that is being done is a rewrite.
I've heard enough people abuse the term to realise that
/for them/
it is largely a euphemism for rewriting.
You don't have to perpetuate their abuse.

--
Chris "sheesh" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Nov 5 '07 #40
Ian Collins wrote:
Malcolm McLean wrote:
>XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to
force a alien mould onto the programmer. There's more it than that, of
course, but the marketing aspect shouldn't be downplayed.
There's a lot more to it than that.
And less of the rechristening than Malcolm implies.

--
Chris "chris again" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Nov 5 '07 #41

"Ian Collins" <ia******@hotmail.comwrote in message
Malcolm McLean wrote:
>XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to
force a alien mould onto the programmer. There's more it than that, of
course, but the marketing aspect shouldn't be downplayed.
There's a lot more to it than that.
Option 1:
"We use some fairly simple techniques to increase productivity. Nothing that
an averagely competent programmer couldn't pick up and see the sense of in a
few days".
Option 2:
"We use a very advanced and sophisticated methodology in which I am an
expert."

Which is more likely to advance the interests of the project? Which is
likely to advance the interests of the manager?
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 5 '07 #42
On Mon, 05 Nov 2007 07:26:43 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>Mark McIntyre wrote:
>On Sat, 03 Nov 2007 20:33:27 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>>Malcolm McLean wrote:
However it is a good thing to have a buzzy term for "rewrite". "Rewrite"
carries too many negative connotations. Appearances matter. It shouldn't
be that way, but it is.

No, you should call a spade a spade. If you have to hide behind buzz
words, either your organisation and/or process is broken.

Welcome to Fantasy island. :-)

Show me a senior manager who prefers "rewrite" to "refactor", or
"sack" to "downsize" for that matter.

Me?
IME you're in a minority of two.

And I've yet to meet any board member who would use the word "fire"
when another more user-friendly word was available.
--
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
Nov 5 '07 #43
On Mon, 05 Nov 2007 10:51:11 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>Ian Collins wrote:
>Malcolm McLean wrote:
>>XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to
force a alien mould onto the programmer. There's more it than that, of
course, but the marketing aspect shouldn't be downplayed.
There's a lot more to it than that.

And less of the rechristening than Malcolm implies.
Well, I can see you two have bought the marketing spiel... :-)

gd&r.
--
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
Nov 5 '07 #44
Mark McIntyre wrote:
On Mon, 05 Nov 2007 10:51:11 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>Ian Collins wrote:
>>Malcolm McLean wrote:
XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to
force a alien mould onto the programmer. There's more it than that, of
course, but the marketing aspect shouldn't be downplayed.

There's a lot more to it than that.
And less of the rechristening than Malcolm implies.

Well, I can see you two have bought the marketing spiel... :-)

gd&r.
Nope, just spent time with the originators and some early adopters of XP
and converted a company over to it with very successful results. No
marketing in sight.

--
Ian Collins.
Nov 6 '07 #45
Malcolm McLean wrote:
>
"Ian Collins" <ia******@hotmail.comwrote in message
>Malcolm McLean wrote:
>>XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to
force a alien mould onto the programmer. There's more it than that, of
course, but the marketing aspect shouldn't be downplayed.
There's a lot more to it than that.
Option 1:
"We use some fairly simple techniques to increase productivity. Nothing
that an averagely competent programmer couldn't pick up and see the
sense of in a few days".
Option 2:
"We use a very advanced and sophisticated methodology in which I am an
expert."

Which is more likely to advance the interests of the project? Which is
likely to advance the interests of the manager?
I was an outright cynic after reading the publicity materials, I was
converted after seeing the process in action and spending some time with
its originator.

--
Ian Collins.
Nov 6 '07 #46
Mark McIntyre wrote:
On Mon, 05 Nov 2007 10:51:11 +0000, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:
>>Ian Collins wrote:
>>Malcolm McLean wrote:
>>>XP works very largely because it reChristens existing practise, such as
rewriting code, patch and fix, and feature creep, instead of trying to
force a alien mould onto the programmer. There's more it than that, of
course, but the marketing aspect shouldn't be downplayed.

There's a lot more to it than that.

And less of the rechristening than Malcolm implies.

Well, I can see you two have bought the marketing spiel... :-)
Independently of whether I've bought into the spiel, Malcolm is not
accurately representing the content of XP as portrayed by the books
by its proponents and the XP & TDD mailing lists. You may -- and
some have -- critique the actual practices of XP or claim that its
areas of applicability are not usefully wide, but claiming that
"XP works very largely because it reChristens existing practise,
such as rewriting code, patch and fix, and feature creep" is,
in my view, both inaccurate and actively misleading.

--
Chris "I'd better stop now" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Nov 6 '07 #47
On Tue, 06 Nov 2007 23:31:55 +0530, santosh <sa*********@gmail.com>
wrote:
>On Tuesday 06 Nov 2007 11:06 pm Charlie Gordon <ne**@chqrlie.orgwrote
in article <47***********************@news.free.fr>:
>"Richard" <rg****@gmail.coma écrit dans le message de news:
s7************@news.individual.net...
>>"Malcolm McLean" <re*******@btinternet.comwrites:

low skilled people can not code anything up in C.

I agree: they seem more likely to do so in C++, Perl, java, php,
javascript, python...

C aint for sissies ;-)

I would dispute including C++ in that list. If anything, it's even
trickier to use properly than C, IME.
Most programming languages are a bit like a violin... pretty easy to
use, but bloody difficult to use _well_ without years of practice.
--
PGP key ID 0xEB7180EC
Nov 7 '07 #48

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

19 posts views Thread by Eric Lindsay | last post: by
29 posts views Thread by Xah Lee | last post: by
11 posts views Thread by R. Rajesh Jeba Anbiah | last post: by
25 posts views Thread by John Nagle | last post: by
5 posts views Thread by electricaljello | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by haryvincent176 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.