Re^2: How to write programs?

Never work at a frantic pace... Better (mis)inform the client on how long it will take you to accomodate changes... If you do it faster, you will be a hero. Don't test for too long... it will fail in production environment anyways ;-) There are subtle undocumented changes between test and production environments that introduce new bugs...

--------------------------------
An idea is not responsible for the people who believe in it...

Comment on Re^2: How to write programs?

Replies are listed 'Best First'.
Re^3: How to write programs? by chromatic (Archbishop) on May 26, 2005 at 21:19 UTC
There are subtle undocumented changes between test and production environments that introduce new bugs... Step 0. Remove all changes between test and production environments that introduce new bugs, no matter how subtle or undocumented.	[reply]
Re^4: How to write programs? by jordanh (Chaplain) on May 27, 2005 at 16:48 UTC
Step 0. Remove all changes between test and production environments that introduce new bugs, no matter how subtle or undocumented. I assume you test in the production environment. Or, you have a test environment that: Duplicates all the Production System's configurations and databases exactly. Duplicates loading and all external interface interaction with the Production System exactly. Has exactly the same hardware as your production system. Has a parallel set of operation's people performing exactly the same operations on it. Oh, and while you are at it, how do you setup a test environment that's exactly like the production environment when the test environment has additional loading from the program under testing? Which is why I assume you must be testing in production. The fact is, differences between your test and production environments cannot _introduce_ new bugs into a program, only exhibit bugs that are inherent in the program that are expressed in different environments.	[reply]