in reply to How to write programs?

Depending upon the program:

1. Ensure requirements are well-written, fully explained and completed.
2. Double check that requirements are finalized.
3. Break down the task into sub-tasks (be that OOP or otherwise)
4. Pseudo-code tests (documenting major functionality)
5. Write tests (I admit I don't usually do this)
6. When the requirements change (and they always do), work at a frantic pace to accomodate, introducing bugs and other undesirable things.
7. Test until you drop
8. Repeat 6 and 7 ad nauseum

Replies are listed 'Best First'.
Re^2: How to write programs?
by bofh_of_oz (Hermit) on May 26, 2005 at 19:30 UTC
    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...

[reply]
      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]
          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]
Re^2: How to write programs?
by adrianh (Chancellor) on May 27, 2005 at 09:42 UTC
    1. Ensure requirements are well-written, fully explained and completed.
    2. Double check that requirements are finalized.

    Following these rules strictly would probably mean that I would never get to stage 3 :-)

    This is why I like techniques that allow clients to change the requirements in a structured way - because there is nothing like having a partial implementation in front of you to make you realise what you really wanted.

[reply]

In Section Meditations