I almost always write tests, sometimes first. Doing documentation first as well is more burden than I can afford.
Besides, I don't think it's a great way to produce good end-user documentation: it easily leads to fragmentation and incoherence. To make things clear, I really need to have a good gestalt understanding of this feature in context, and that often requires writing the docs for a suite of features together, once they're all implemented and I have the wrinkles ironed out. Writing the documentation first, before I've found out how things need to be tweaked to work *well*, is a recipe for inaccuracy.
Granted, this may work decently in your space, where the script is taking very specific inputs and creating very specific outputs. But in end-user software, getting the fiddly UI and behaviour details right is often 2/3 of the problem, and it's rare to guess those details correctly at the start...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2008-10-22 12:50 am (UTC)Besides, I don't think it's a great way to produce good end-user documentation: it easily leads to fragmentation and incoherence. To make things clear, I really need to have a good gestalt understanding of this feature in context, and that often requires writing the docs for a suite of features together, once they're all implemented and I have the wrinkles ironed out. Writing the documentation first, before I've found out how things need to be tweaked to work *well*, is a recipe for inaccuracy.
Granted, this may work decently in your space, where the script is taking very specific inputs and creating very specific outputs. But in end-user software, getting the fiddly UI and behaviour details right is often 2/3 of the problem, and it's rare to guess those details correctly at the start...