On 4/20/2012 1:14, Invisible wrote:
>> In practice, it's usually not that hard, because the likelihood that you
>> need to break 25 separate classes is low if you've designed your code
>> decently.
>
> Apparently having 25 token classes is "not designing your code decently"
> then...

Note that if what you're changing is mindless, then sure, make lots of 
changes. If you're (for example) renaming a routine inherited by 25 classes 
or something, sure.

If you have to spend an hour on each one thinking how to fix it, chances are 
you're either making too big a change, or your design was wrong to start 
with. (Of course, fixing that design implies breaking 25 classes, so...)

>> That's part of it, but you still have to merge it back in, which is
>> going to be a mess of 25 people have been working on the 25 classes
>> you've been changing.
>
> Isn't that why you /talk to/ the other developers?

Sure. If you can get people to stop development on those things for however 
long it takes you to fix them, that works. Sometimes that's not feasible. 
Especially if it's live production code.

> I'm pretty sure that without communication, any development effort is doomed
> to end in failure. Multiple people developing the same code, fixing the same
> bugs different ways, and generally getting in each other's way.

Sure. But if those 25 classes are in (say) 25 different projects run by 25 
different groups, you're going to get in their way. If you're changing the 
parser library, and you affect everyone in your 15,000-developer company 
that uses that parser library, you're going to have a world of trouble 
getting everyone to stop.

>> Tk is still, in many ways, stuck in the 80's of X-Windows development.
> Yeah, I never did like Tk. :-P

It has always been ugly, yes. :-)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message