This little story from Folklore.org: Macintosh Stories: Inside Macintosh illustrates why I think products should be developed with the participation of all the involved players – documentation, QA, support, sales, implementation, trainers, customers – and not just engineering and product management.
The next week I sat down to meet with Caroline for the first time, and she couldn’t have been more different than the previous writer. As soon as I began to explain the first routine, she started bombarding me with questions. She didn’t mind admitting it when she didn’t understand something, and she wouldn’t stop badgering me until she comprehended every nuance. She began to ask me questions that I didn’t know the answers to, like what happened when certain parameters were invalid. I had to keep the source code open on the screen of my Lisa when I met with her, so I could figure out the answers to her questions while she was there.
Pretty soon, I figured out that if Caroline had trouble understanding something, it probably meant that the design was flawed. On a number of occasions, I told her to come back tomorrow after she asked a penetrating question, and revised the API to fix the flaw that she had pointed out. I began to imagine her questions when I was coding something new, which made me work harder to get things clearer before I went over them with her.
As I embark on my second full development cycle at the good company where I work, I’m writing my initial design documents with an eye to the specific information I’ll need when I’m handing off the finished version to other departments and customers.
Foresight. Yes, it’s partly that. But it’s also those great virtues coming around again: Laziness, Impatience, Hubris.
(Thanks to Chris P. for pointing me at the Folklore.org story)
MetaGrrrl 