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.
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.
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.
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.
The second step is writing tests.