* Buddy Burden <[EMAIL PROTECTED]> [2008-03-29 20:55]:
> I just think that having code where every time you change
> things in one place, you have to make sure you change something
> somewhere else isn't a good thing. In any other programming
> scenario, I think most everyone would agree with me.

I agree with you even when it comes to plans. The fact that they
require you to make lock-step changes in different places of the
code is unfortunate.

> But when it comes to testing, doing this in terms of tests is
> not only okay, it's considered best practice.

No, just intrinsically inevitable, as far as I can tell anyway.
(However, for many cases there are patterns you can adopt to
minimise the problem – of course, that still imposes a tax on
every unit within your test file.)

A plan is a declaration, much like explicit static typing, that
affords you certain protections at a certain cost. Experience is
that by and large, the bottom line for plans is positive: for a
small but continuous cost they will catch some very hard to debug
false negatives. They are basically an insurance, in this sense.
And as with insurances, it is clearly possible that the expense
is disproportionate with the safety you get in return.

But even when the protection you get is worthwhile, the necessity
of distributed changes doesn’t suddenly become a good thing. It’s
just a means that’s justified by the ends.

Overall, I’m reminded of something MJD said in his Program Repair
Shop and Red Flags talk at YAPC::Asia 2007:

    Also I’m trying to get away from right and wrong. This is not
    about morals; it’s engineering. And so, well, things can be
    suboptimal – maybe they aren’t designed as well as they could
    be –, but they’re not wrong, probably.

(The recording is available online, btw, at
<http://video.google.com/videoplay?docid=-4037440245833870135>.
If you haven’t seen it, I can only recommend you do. None of it
is surprising in the least for a seasoned good programmer (or so
I’d hope), but it’s very lucidly explained.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Reply via email to