Re: For Dan Johnson: more app rewrites

"Daniel Johnson" <danieljohnson2@xxxxxxxxxxx> stated in post
13p9295lb1rdlaf@xxxxxxxxxxxxxxxxxx on 1/21/08 4:59 AM:

"Snit" <CSMA@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C3B942A3.A35E0%CSMA@xxxxxxxxxxxxxxxxxxxxxxxx
"Daniel Johnson" <danieljohnson2@xxxxxxxxxxx> stated in post
13p7ln3gq4t5684@xxxxxxxxxxxxxxxxxx on 1/20/08 4:19 PM:
[snip- the need for rewrites]
Still, that "less code" will still get more complex and messier as it
matures.

Sure, but it will do more with less.

Ah, well, not really. If you rewrite, you almost inevitable wind up doing
less (with less code). Yeah, the functionality-code ratio tends to shift
towards more functionality, but mature codebases have such a lot of
functionality that you are pretty much guaranteed to lose on that front
anyway.

In the short run, perhaps... but look at OS X... a completely re-write that
does more.

[snip]
Sometimes the foundation needs to be ripped out and replaced... pretty much
starting from scratch.

Out of curiosity.. how would you tell when this has happened?

Not sure there is an exact calculation - but when fixes break other things
too often and the program gets to slow and parts are inconsistent with each
other that is likely a pretty good sign.

I'm afraid fixes *always* break other things "too often", and there is always
inconsistency between parts of a program of any size.

But not all programs share these traits equally. As it gets "too bad",
however you rate that, it is time to do something drastic.

And rewriting will almost inevitably make your program slower, as you'll lose
all the optimization you did before- and if you use the latest tools, they'll
product slower results too.

The new iMovie is *much* faster than the old. Much.

I would suggest a good rule of thumb is this: If you cannot enhance the
program further due to the quality of the code, and you also cannot correct
the quality problem, then a rewrite is justifiable. If you can do the rwrite
with better quality, you can then enhance the program from there, so you have
gained something. And if the program is as bad as I have described, you have a
good chance to do that.

[snip]




--
One who makes no mistakes, never makes anything.

.

Relevant Pages

  • Re: For Dan Johnson: more app rewrites
    ... matures. ... you almost inevitable wind up doing less. ... I would suggest a good rule of thumb is this: If you cannot enhance the program further due to the quality of the code, and you also cannot correct the quality problem, then a rewrite is justifiable. ...
    (comp.sys.mac.advocacy)
  • Re: Advice needed
    ... Typically when they do that they lose a lot of functionality that they had built over time, while at the same time adding a whole new set of bugs. ... If you are asking them to do a massive rewrite you need to have a convincing business case. ... Will you save on the cost of new hardware enough to justify the cost of new development? ...
    (microsoft.public.dotnet.general)
  • Re: Chrome - competition for Borland?
    ... >> previous level of confidence and quality. ... cost of the rewrite? ... If you rewrote the app to run in .NET but the firm's bottom line ...
    (borland.public.delphi.non-technical)
  • Re: f77 and dynamic arrays in common blocks
    ... "Charles Russell" writes: ... > believe it counterproductive to mix programming styles. ... I didn't even think about recommending that they rewrite it. ... And I probably wouldn't add new functionality by modifying the old ...
    (comp.lang.fortran)
  • Re: Delphi 2008 native?
    ... Cutting yourself off from a lot of functionality, present and future, just to avoid .Net is rather shortsighted. ... just the contrary - the development system is not stable and every ... This keeps coming up, the idea that, if it really were good, then MS would rewrite years worth of perfectly good working Win32 code in .Net just to prove it. ...
    (borland.public.delphi.non-technical)