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. 47  1665 
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
"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
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
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".
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
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
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
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)
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
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
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.
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
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
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
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
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.
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.
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
"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
"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.
"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
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.
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.
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!
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.
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.
Ian Collins <ia******@hotmail.comwrote:
people centric development process.
Bucket, please.
Richard
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
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
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
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
"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
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.
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
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
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.
"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
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.
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
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
"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
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
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
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.
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.
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Matt |
last post by:
How do we define systems programs? when we say systems programming,
does it necessary mean that the programs we write need to interact
with hardware directly? For example, OS, compiler, kernel,...
|
by: Gary James |
last post by:
This may not be a direct C# question, but since I'll be using using C# for
development, I thought I'd pose the question here.
I'll soon be involved in the design of a new software product that...
|
by: Eric Lindsay |
last post by:
Should HTML 4.01 Strict markup be done in upper case or in lower case?
I understand that HTML allows either upper or lower case. I also notice
that XHTML apparently requires lower case. However I...
|
by: Xah Lee |
last post by:
Computer Language Popularity Trend
This page gives a visual report of computer languages's popularity, as
indicated by their traffic level in newsgroups. This is not a
comprehensive or fair...
|
by: R. Rajesh Jeba Anbiah |
last post by:
FWIW....
I see, some old regulars--Pedro Graca, Nikolai Chuvakhin, Manuel
Lemos, Janwillem Borleffs,... back now--but some others like Chung
Leong, Andy Hassall, Erwin, John Dunlop, Justin...
|
by: John Nagle |
last post by:
Some faster Python implementations are under development.
JPython has been around for a while, and PyPy and ShedSkin
continue to move forward. It's worth thinking about what slows
down Python...
|
by: editormt |
last post by:
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...
|
by: electricaljello |
last post by:
Hello,
Just wondering if anyone can offer advice (perhaps based on
experience) on how to deploy and license a C++ based app as a
commercial library. The main questions I'm trying to answer are...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
