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

Actually, it took me about 20 minutes to fix all the changes. It's just 
that for those 20 minutes, the code is broken. And if anybody got some 
of the commits but not the rest, that'd have broken code.

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

Which leads me back to "isn't that what branches are for?"

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

So create a new branch. Play around with the new design in your 
experimental branch. /When it's finished/, merge it back into the main 
trunk.

Isn't that how this game is supposed to work?

Post a reply to this message