need reference on "when to rewrite"

[not_a_commie]

I've seen studies before showing that it is better to rewrite code
when more than 25% (or whatever) of the code needs to be changed. I
can't seem to locate any references for that at the moment. Do any of
you have references for that type of article? Thanks.

[Peter Duniho]

On Wed, 13 Jun 2007 12:34:54 -0700, not_a_commie <no********@gmail.com>
wrote:

I've seen studies before showing that it is better to rewrite code
when more than 25% (or whatever) of the code needs to be changed. I
can't seem to locate any references for that at the moment. Do any of
you have references for that type of article? Thanks.

I can't imagine any authoritative answer to the general question. There
are a number of factors, including but not limited to: how do you quantify
what needs or will be changed? how do you define "better"? how do you
weigh the competing priorities of ease-of-maintenance and rapid code
development? how will the change affect future development, if at all?
How much time can you afford to apply to rewriting the code?

That said, my highest priority is almost always code correctness and
clarity, along with ease of maintenance (these things all go hand in
hand). In my professional life, these goals have not always been
appreciated by those around me, but it seems to me that there's too much
bad code out there to allow an opportunity to fix bad code go by without
taking advantage of it.

In other words, my general rule is that if the code needs rewriting, I
rewrite it. Even if I find myself in a situation where, to accomplish the
immediate goal, only a relatively small portion of the code _must_ be
changed, if I can improve the overall reliability of the code by rewriting
that component, and I can do so in a reasonably practical amount of time,
I do.

Pete

[Samuel R. Neff]

I've seen lot so articles that say it's never good to rewrite from
scratch. Really it's a matter of opinion, so if you choose your
opinion I'm sure you can find an article to back you up (or if not,
write one).

My opinion is that there are three times to rewrite something--if the
language/platform change and rewriting is the only real option, if the
old thing is so poorly written that maintaining the code is
considerably harder than it would be if it was written better, or if
the component or whatever needs to be rearchitected to enable some new
feature or extension of enhancement that is not possible under the old
code.

HTH,

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Wed, 13 Jun 2007 12:34:54 -0700, not_a_commie
<no********@gmail.comwrote:

>I've seen studies before showing that it is better to rewrite code
when more than 25% (or whatever) of the code needs to be changed. I
can't seem to locate any references for that at the moment. Do any of
you have references for that type of article? Thanks.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

not_a_commie wrote:

I've seen studies before showing that it is better to rewrite code
when more than 25% (or whatever) of the code needs to be changed. I
can't seem to locate any references for that at the moment. Do any of
you have references for that type of article? Thanks.

To be a little cynical:

quality of code = % of code to change that will make you rewrite all

There are really bad code that will make you want to rewrite if you
just need to update the copyright year.

There are very good code where you can replace almost everything
without wanting to change the rest, because it is as it should
be.

Arne

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

In other words, my general rule is that if the code needs rewriting, I
rewrite it. Even if I find myself in a situation where, to accomplish
the immediate goal, only a relatively small portion of the code _must_
be changed, if I can improve the overall reliability of the code by
rewriting that component, and I can do so in a reasonably practical
amount of time, I do.

I doubt that the QA people and the project manager likes that
approach ...

Arne

[Peter Duniho]

On Wed, 13 Jun 2007 19:37:18 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

I doubt that the QA people and the project manager likes that
approach ...

Well, a) who cares? IMHO, having the code be correct is more important
than some political games. And b) I never had any complaints from those
people along those lines. In fact, if anything, the biggest complaint my
testers had was that their bug find rate was too low when they were
working in my areas of a project.

Probably the biggest disadvantage to my approach was that most of my
career I've been in environments in which the two biggest review criteria
were how fast do you call yourself "feature complete" and how many bugs
can you fix after "feature complete" (the more, the better). That
environment strongly encourages sloppy coding, because not only can you
get the code done quickly, you can introduce LOTS of bugs that then add to
your bug fix count.

I would invariably get less code written than other people, and then have
fewer bugs to fix than those same people (in fact, I never had enough bugs
to fully occupy my time, so I always wound up fixing other people's bugs
too, but that takes a lot more time than fixing bugs in code you're
familiar with), leading to poor performance reviews. But I view
programming as an art and a craft, and I just don't see myself sacrificing
quality in my art just to please some silly review structure.

I realize that the industry standard is to cobble something up as quickly
as possible, and then try to work out all the little wrinkles after the
fact. But the industry standard is also to release incredibly crappy
code. That's just not how I work.

Pete

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Wed, 13 Jun 2007 19:37:18 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

>I doubt that the QA people and the project manager likes that
approach ...

Well, a) who cares? IMHO, having the code be correct is more important
than some political games. And b) I never had any complaints from those
people along those lines. In fact, if anything, the biggest complaint
my testers had was that their bug find rate was too low when they were
working in my areas of a project.

You change the implementation of some functionality that are
not in the test plan.

Arne

[Peter Duniho]

On Sat, 16 Jun 2007 17:15:00 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

You change the implementation of some functionality that are
not in the test plan.

Oh, give me a break.

I never said anything about going off and rewriting code without
information the testers that there are changes to be tested. You are
making way more assumptions that are justified here, for what purpose I
have no idea.

The original question did not ask specifically about multi-person
projects. It was a very simple question about the general philosophy
regarding rewriting code. It is true that in larger projects, there are
other factors to consider, but so what? People involved in those larger
projects are expected to have the competence to consider those factors (or
at least be managed by people who do).

Quit making a mountain out of the molehill.

Pete

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Sat, 16 Jun 2007 17:15:00 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

>You change the implementation of some functionality that are
not in the test plan.

Oh, give me a break.

I never said anything about going off and rewriting code without
information the testers that there are changes to be tested. You are
making way more assumptions that are justified here, for what purpose I
have no idea.

I wrote:

#I doubt that the QA people and the project manager likes that
#approach ...

You replied:

#Well, a) who cares?

The original question did not ask specifically about multi-person
projects. It was a very simple question about the general philosophy
regarding rewriting code. It is true that in larger projects, there are
other factors to consider, but so what? People involved in those larger
projects are expected to have the competence to consider those factors
(or at least be managed by people who do).

People in almost any software development are expected
to care what project managers and QA people may have to say
about rewriting code.

Arne

[Peter Duniho]

On Sat, 16 Jun 2007 18:48:22 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

People in almost any software development are expected
to care what project managers and QA people may have to say
about rewriting code.

IMHO, there is a difference between keeping those people informed, and
allowing them to make rewrite decisions for you. It's the latter that I
was commenting on. If you are arguing that they should be involved in the
decision as to whether to rewrite the code, I disagree. It's one thing,
and acceptable to me, to allow them to provide input regarding the
schedule, so that _you_ can make an informed decision about what is
practical (note that I several times in my original post addressed the
question of practicality). It's another entirely to allow them a hand in
the decision-making itself. And I disagree with you if it's your position
that one should do that.

Pete

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Sat, 16 Jun 2007 18:48:22 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

>People in almost any software development are expected
to care what project managers and QA people may have to say
about rewriting code.

IMHO, there is a difference between keeping those people informed, and
allowing them to make rewrite decisions for you. It's the latter that I
was commenting on. If you are arguing that they should be involved in
the decision as to whether to rewrite the code, I disagree. It's one
thing, and acceptable to me, to allow them to provide input regarding
the schedule, so that _you_ can make an informed decision about what is
practical (note that I several times in my original post addressed the
question of practicality). It's another entirely to allow them a hand
in the decision-making itself. And I disagree with you if it's your
position that one should do that.

The QA people has a responsibility for testing all touched code
within the project deadlines.

The project manager has the overall responsibility for the
project deadlines.

If they say no to the change then the developer can not
make an "informed" decision to do the change anyway.

He would be out the door first time it was discovered.

Arne