1. 10

  2. 2

    I had a boss once who wrote the documentation first, then the code, then tests. I’ve tried to adopt it, a few times, but keep falling for the temptation to start coding.

    1. 2

      I’ve been doing this for a long time and I find it really helpful. I’m not so sure it’s necessary to share the document, but gathering your thoughts is a good idea. I often start out by writing a large comment somewhere in a file when I go to write something of substance. That comment tends to not stick around, but is sure prevents a lot of useless refactoring.

      Going too far with this leads to over-specified requirements documents, which is how “process” got to be a four-letter word.

      1. 1

        The second step is writing tests.