>Peter,
>
>If that was ALL the code it would be very bad indeed.
>But if it was deeper in some process it is of course legitimate to presume that any required editing (called validation today) has been done and dealt with.

Okay, so, you agree that the train driver need not check time and again whether there is rails ahead indeed, but you plea that he should check their existence upon start of the journey?

I don't see the advantage. Suppose an application really needs employee.dbf and that table is wiped out by some stupid user. What's bad about an app that therefore crashes (yes, crashes) on startup?

>Two comments about the concept:
>
>1) I've heard of (but never seen) a manager seeing a prototype, which is normally written using this "concept" saying 'that's good enough as-is. Put it into production'.

Poor manager, possibly even literally poor.

>2) A high percentage of programming involves editing (now called validation) of input. One could surely cut programming time dramatically using this 'technique' but I dare say users would tar-and-feather him pretty soon.

To be clear about it, I'm not advocating Thundering Train Programming as THE technique for whole applications. But I have the feeling that certain, as such identified, parts of applications can be safely done using this technique. A crash in such a part is, well, an error message and eventually some data damage. The data and the code will need some repair indeed. But is that really always a bad thing?