RS> Proper maintenance catches most of that stuff, compile and pray doesnt.

PE> BTW, "compile and pray" is a gross misrepresntation of reality.

Yes, its a shorthand description of an approach which IMO isnt the
sort of testing *I* do on code that doing something *I* care about
the results of.

PE> I don't have a test environment for QWK, since I don't use
PE> it. However, Brenton does, so I get him to do the testing.

And since that problem with with the pre 221 netmail didnt get
picked up by that testing, it obviously has some deficiencys.
So I am not planning to rely on that testing myself.

PE> In fact, I tell him what tests to do (ie send netmail to these two
PE> people etc), and he does, and I have a look at the incoming netmail
PE> or packets and see if they have the expected control lines in it.

Welp, whatever went wrong, it didnt pick up the problem that lurked
for quite a while.

It ALSO didnt pick up the problem with the MAKEMAIL.BAT in TinyPoint.

So maybe you can see why I choose to do more testing that that.

PE> It's even better than doing my own tests, because it is being
PE> used in a live situation.

Yes, its certainly better, but IMO not good enough for me to use it
without further testing.

PE> Brenton hasn't complained yet, and it suits me down to the ground,
PE> and the end result is that it works.

It doesnt, atleast TWO very significant problems have got thru that
testing protocol. Three really should the even worse problem of the
incoming mail ALL being filed in the bin got thru too.

PE> And when it does work, I THEN make it available to everyone else.
PE> That's why you always see Brenton using a later version of PQWK
PE> before anyone else (for anyone who can read the PID anyway).

And obviously Bob and Dieter are happy with that level of testing.
*I* and apparently Frank want to do more before we use it.

--- PQWK202