Martinek, Carla wrote: > Brings up an interesting topic for discussion: > > How many of you have had reviewers/SMEs outright LIE to you on > something, or provide you with incorrect info and deny it, etc.? I don't know that they deliberately lie, but I have been provided with incorrect and incomplete information numerous times. Luckily, none have ever denied that s/he gave that information, but I tend to skip the whole blame-game and get on with correcting the documentation.
From my experience, I've found that there are two reasons that a programmer provides incorrect information: 1. Our programmers are very literal and therefore provide answers specifically to the situation presented. They see the conditions and recognize any special cases, but don't mention that the situation is special. The person asking the question then interprets the special case as the global practice. I suspect this trait is common among most programmers/engineers/techies (I tend to do this, too, although I have trained myself to be sure to explain that it is a special case). 2. The programmer honestly believes that the system operates a specific way, using a specific value, because s/he isn't aware that a peer fixed an issue 2 years ago by using a different value. As a result, I make it a point to ask if this example is a special case. However, both issues can be resolved by testing and verifying the expected results. The first time I discovered that a programmer didn't provide the correct information, I had documented what I thought was a fairly simple topic. At that time, we didn't have a very good testing environment, so I had to rely specifically on the programmer to get to the nuts and bolts. We met a couple of times, hammered out the process, I documented it, and moved on to other topics. Two years later, someone asked a question, and I realized that I needed to revise the documentation to include that part of the puzzle. By that time, we had a much improved testing environment, and I had changed my process to test before asking question, not to mention that I had gained access to a lot more resources so that I didn't have to rely on the programmers quite so much. In testing the proposed changes, I discovered that *everything* the programmer had originally told me about this particular topic was just plain wrong, and that it was much more complex than I ever imagined. I ended up investing over 6 months on the project. The original project, when placed in a word doc, was roughly 10 pages long. The revised project was over 80. Yeah, complex. I need to revisit another project that I documented about the same time as that original project. I trust the programmer I worked with on this second one a lot more than I do the one on the first, so I'm not anticipating a lot of revisions. However, some issues have been raised recently, and they call into question some of the details. In many ways, I've become much more of a tester than I have a technical writer. I don't know that I'd want to go back to the "old way" of strictly relying on someone else to tell me how a feature works - I prefer to get my hands dirty and analyze the results myself. -- JWH ______________________________________________ Author Help files and create printed documentation with Doc-To-Help. New release adds Team Authoring Support, enhanced Web-based help technology and PDF output. Learn more at www.doctohelp.com/tcp. DOCUMENTATION & TRAINING WEST 07: THE USER EXPERIENCE April 18-21, 2007 ~ Vancouver BC ~ Marriott Pinnacle ~ free city tour 40+ sessions * free workshops * free iPod offer * www.doctrain.com _______________________________________________ Technical Communication Professionals Post a message to the list: email [EMAIL PROTECTED] Subscribe, unsubscribe, archives, account options, list info: http://techcommpros.com/mailman/listinfo/tcp_techcommpros.com Subscribe (email): send a blank message to [EMAIL PROTECTED] Unsubscribe (email): send a blank message to [EMAIL PROTECTED] Need help? Contact [EMAIL PROTECTED] Get the TCP whole experience! http://www.techcommpros.com
