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

Yes... because programs don't run on rails <s>.

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

Fox might just issue a open file dialog with no indication of which file is needed. To put the user through such aggravation is almost criminal. Most users I've encountered don't understand error messages and fewer still feel the need to write them down before they call me. How would you expect a USER to find/fix the problem?????


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