RE: What is not mandated is forbidden

Subject: RE: What is not mandated is forbidden
From: "McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
To: Steven Jong <stevefjong -at- comcast -dot- net>, TECHWR-L Digest <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Mon, 23 Jun 2014 15:12:27 -0400

In systems where more than one person might have a hand, either serially or concurrently, it's very possible that a given user wouldn't get to see what the default is (if they aren't explicitly told). S/he'd get to see what somebody else had set. They might like to know the likely effects of modifying the current settings in one direction or another, either to decide whether to update what they inherited (config-wise) or to argue/discuss with other admins about their current setting choices.

And, absolutely, you are describing real situations.

I made a table for my readers, showing how logging level and log-file roll-over settings interact to affect disk-space and other aspects of performance.
But........ that was before we started getting serious about agile development and tracking methodology, now that I think of it.

-----Original Message-----
From: Steven Jong

I think the original question touches on the premises of minimalism. As such, it's interesting to discuss.

Imagine a product with event logging. You can set the logging level to five values, from terse (fatal errors only) to chatty (debug messages for every event). Minimally, you can document that there is logging, there are five levels, here they are, here's the default, and here's how to set them.

By the principals of minimalism, that's all you need to say. (Maybe even that is too much. Here's how to set log levels. Go explore! Customers will see the default at once, and they can determine for themselves what works for them.)

But it may be that setting the logging level to "terse" results in important errors, such as the system hanging, going unrecorded. It might also be that setting the logging to "chatty" floods the log, fills the disk, and ruins performance. It may be that customers call Support all the time with both these problems. (And it may be that I'm not making this up, but rather describing real situations 8^)

Perhaps I misinterpret minimalism. But I'm not misinterpreting the product line manager who would say not to include such a statement: he's wrong. Good advice is valuable; I care to minimize support costs; I care to maximize doc value; I care to improve the user experience; I care to just plain do my job. From any of those perspectives, I would include the information, both my example and yours.

The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.

Doc-To-Help 2014 v1 now available. SharePoint 2013 support, NetHelp enhancements, and more. Read all about it.

Learn more:


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @

Re: What is not mandated is forbidden: From: Steven Jong

Previous by Author: RE: What is not mandated is forbidden
Next by Author: Workflow, issue-tracking, resolution, whoops
Previous by Thread: Re: What is not mandated is forbidden
Next by Thread: PDF comment reply text not showing - Acrobat XI Pro

What this post helpful? Share it with friends and colleagues:

Sponsored Ads