A Trend Towards Lower Software Maintenance Budgets?

[Richard]

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.

 

[Malcolm McLean]

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.

 

[Richard]

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

This might be your experiences and can be the case in poorly designed
systems.

"rewriting". The insight is that generally it is cheaper to scrap code
and start over than to try to modify.

Its a case by case thing and there are no hard and fast rules. Sometimes
it is impractical to rewrite since there is no suitable design
documents from the original documenting each and every data state and
which ones are important to keep in order to correctly process the
legacy data.

My main point is this : it is certainly not true that if 20% of the code
base must be modified then its better to rewrite the entire system in
all cases. In fact, I suspect its only valid in a very small %.

 

[Malcolm McLean]

Its a case by case thing and there are no hard and fast rules. Sometimes
it is impractical to rewrite since there is no suitable design
documents from the original documenting each and every data state and
which ones are important to keep in order to correctly process the
legacy data.

Document each and every data state? Wouldn't it be easier just to say that
the code documents each and every possible state of the algorithm?

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.

 

[Richard]

Document each and every data state? Wouldn't it be easier just to say
that the code documents each and every possible state of the
algorithm?

Yes. it would be easier to say that. But in the real world code often
does a lot more than people think....

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.

 

[James Kuyper]

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.

 

[Richard]

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.

 

[James Kuyper]

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.

Is higher possible? :-;

Thanks for the vote of confidence!

 

[Ian Collins]

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]

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.

 

[Richard Bos]

people centric development process.

Bucket, please.

Richard

 

[Flash Gordon]

Ian Collins wrote, On 02/11/07 05:45:
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.

 

[Chris Dollin]

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.

 

[Mark McIntyre]

people centric development process.

Bucket, please.[/QUOTE]

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

 

[Mark McIntyre]

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

 

[Chris Dollin]

Ive never said I was judging it. I've been using the technique

Which is "the" technique here? XP isn't "a technique", its a bunch of
practices and an attitude. Do you mean you're an XP-er, or not?

since when people thought digital watches were cool. What I'm judging is
the ludicrous name. There's nothing extreme about it,

Push the practices to their limit -- as TDD and pair-programming do,
for example -- /is/ extreme.

and adding hideous acronym-ready names to methodologies

I'm finding it hard to imagine a /non/-acronymready name. As acronyms
go, XP doesn't seem to be particularly extreme.

[Whether it's a good name or not I shall carefully not have an opinion on.]

makes me reach for the pointed stick.

Methodologies are not vampires. I don't know whether that's a good thing
or not.

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

Brother! No, hand on a mo --

I'll get me coat.

Pub?

 

[Malcolm McLean]

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.

 

[CBFalconer]

.... snip ...


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.

 

[Ian Collins]

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.

 

[Mark McIntyre]

Do you mean you're an XP-er, or not?

I hotly deny that I'm any kind of anything-er.

Push the practices to their limit -- as TDD and pair-programming do,
for example -- /is/ extreme.

We can agree to disagree, I'm sure.

Methodologies are not vampires. I don't know whether that's a good thing
or not.

Its for poking practitioners with, to see if they're alive or zombie
followers.

Pub?

Works for me...

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