> it was in this case far less writing to fix the bug in the code than it would have been to document the intricacies of the misbehavior
I have a design mantra that is a corollary to what I wrote earlier: "it's easier to code to good documentation than it is to document bad code." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, January 09, 2012 4:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Error apply ZAP On Mon, 9 Jan 2012 15:32:26 -0800, Charles Mills wrote: >> The resource spent on adding emphasis to the description of a >> deficiency >would better have been used to repair it. > >LOL. Ain't it the truth! Every software team should have that on a >plaque on the wall. > >I don't always do it, but I am happiest when I do: write the user >documentation BEFORE you write the product. Then when you find yourself >devoting three tedious paragraphs to explaining how something works, >you have a chance to say to yourself "Hmm. Maybe it shouldn't work that way." > I once had a user (in-house), steeped in the MVS culture, come to me and complain that one of my programs was not operating as documented. He requested that I change the documentation (as he would have expected of IBM). I looked at it. The documentation expressed the intent of my design; the implementation was in error. I fixed the latter, and damned the impact on compatibility to users who had adapted to the misbehavior. And besides, it was in this case far less writing to fix the bug in the code than it would have been to document the intricacies of the misbehavior. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
