Prev: Ctalk 0.0.96a 20100606 Released
Next: Simple Hack to get $500 to your home
From: Nick Keighley on 21 Jun 2010 06:59
On 12 June, 05:32, Brett Williams <mungoje...(a)gmail.com> wrote:
> On Jun 10, 6:30 am, Tim Harig <user...(a)ilthio.net> wrote:
>
> > Well, that assumes that there have been no changes in the
> > structure/interfaces of the program that the old implementation requires,
> > that new implementation hasn't lost or modified any information that old
> > implementation needs to do its job, and that the new implementation
> > performs exactly the same task that the old implementation did (including
> > any expected side affects).  If all of those assumptions are valid, and they
> > should be thoroughly tested, then it wouldn't be a bad idea to fall back
> > to the older implementation; otherwise, the old implementation is simply
> > likely to do more harm then good.
>
> Thanks for your reply, Tim!
>
> I've been thinking about your point that the old implementation has
> expectations of the surrounding code.  It seems like there's a sort of
> destructive chain reaction: Each adjustment sends out ripples of
> destruction to everywhere that depended on the old behavior, which
> necessitates more adjustments, that surprise more clients, etc.  I'm
> assuming there's a reason for enduring this chaos, but I'm not
> grokking it yet.

stupidity? laziness? The different parts of the code are insuffiently
isolated. Too few abstraction barriers. Take a look at the Open/Closed
Principle


> I've been trying to think of how to express my idea in other forms
> than try/except, because that's just an example (probably a bad
> example) of what I'm thinking.  I just don't understand in general why
> the process of programming should be so destructive, why the program
> needs to be an amnesiac who only remembers the very last way we taught
> it how to do anything.

well usually new code is supposed to be "better" (in some sense) than
old code. Having two peices of code that do essentially the same thing
is primrose path on the slippery slope. Every time we add new
functionality both NewCode and OldCode have to modified. And tested.


> OK here's another idea: Why not just have every version of every
> routine remain available?

I think I've worked on code like that... No one dared delete anything
just in case it was important. Turning over any stone revealed a can
of worms.


>  We do for instance with versions of a whole
> package of software: Sometimes you have to install both Foo 1.5 and
> Foo 1.6 to run two things that rely on different versions.  Viewing
> the routines in our programs as clients, aren't we always violently
> forcing them to upgrade immediately to the latest versions?
From: Lie Ryan on 30 Jun 2010 09:58
On 06/21/10 20:59, Nick Keighley wrote:
>> > OK here's another idea: Why not just have every version of every
>> > routine remain available?
> I think I've worked on code like that... No one dared delete anything
> just in case it was important. Turning over any stone revealed a can
> of worms.

Probably a more feasible middle alley, is to have the routine available,
with comments of the milestone target where the routine should be
expected to be removed.

Just like adding features are a milestone, removing crufts should also
be a milestone. Without completing the milestone, that particular
version wouldn't be shipped, so you're forced to remove that by the
milestone coming.
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Ctalk 0.0.96a 20100606 Released
Next: Simple Hack to get $500 to your home