>Jim,
>
>Should you not also tell your students that, in the real world,
>
>1. The rules change, and you do not have the time to know what the lastest fad is.
>2. A lot of rules do not really have a reason to exist
>3. You most probably will not finish your project within the delay if you follow the rules.
>
>Unless of course you do not want to create your own competition ....
>
>Only partly joking,
>
Marc,

I know you toungue in cheek with this, but I would like to comment anyway.


>1. The rules change, and you do not have the time to know what the lastest fad is.

Fads are fads and rules are rules and never the twain shall meet. The rules of sound relational datase design were set in the 70's and they remain unchanged. The rules of OO analysis, design, and programming were set down in the 70's and 80's and they remain unchanged.

Some simple rules that will never change;

Loose external coupling is better than tight external coupling

Encapsulation of data and behavior is better than separated data and behavior

Properties of objects are better than variables floating around in memory

Methods of objects are better than UDFs as they allow the encapsulation of data with the behavior

PUBLIC variables stink, they should be avoided at any cost.

Globals should be limited to the fewest as possible.

Any project will be as good as the analysis and design.

Tomatoes are fruit and potatoes are vegetables even though they both end with toe


>2. A lot of rules do not really have a reason to exist

Alot of fads have no reasoning, but every rule for a programming discipline has a reason toe exist. Every rule addesses a potential problem that would exist if the rule were not followed.

>3. You most probably will not finish your project within the delay if you follow the rules.

I have seen alot of projects fail because the rules were not followed