Thursday, May 15, 2008

The dangers of over-precision

While I am sometimes lacksadaisical about the whatsit or the whatever, there are other times in which I am painfully precise about a specific item.

But you don't want to be too precise, as I realized when reading a Laurent Schneider blog post.

Now I should point out that in many cases, Laurent's blog posts go over my head. While I have been known to hang out with Oracle ACEs, I most emphatically do not share their technical expertise. While I can spell BLOG, I wouldn't know what to do with one if it landed on my table.

But, over the decades, I have picked up a bit of knowledge of UNIX (UNIX is a trademark of Bell Laboratories) and its variants, so when Laurent says words like "cron," I have a bit of understanding about what he's discussing. And when he says "man," I know he's not being a sexist pig.

A crontab file consists of lines of six fields each. The fields are separated by spaces or tabs. The first five are integer patterns that specify the following:

minute (0-59),
hour (0-23),
day of the month (1-31),
month of the year (1-12),
day of the week (0-6 with 0=Sunday).


The man page then goes on to say the following:

The specification of days can be made by two fields (day of the month and day of the week). Both are adhered to if specified as a list of elements.

To some people, this is great. If one way to specify days is good, then two days to specify days is even better, isn't it?

Not exactly. In his blog post, Laurent provides an example of a cronjob specification that results in execution on the following days (among others):

  • today (Thursday May 15, 2008) at 2:15pm

  • next year Friday May 15, 2009 at 2:15pm

  • next week Thursday May 22, 2008 at 2:15pm
Laurent's solution was to ignore the manual and only specify one of the two day parameters. Rather than specifying both the day of the month and the day of the week, Laurent only specified the day of the month, which resulted in the behavior that he desired.

Another place in which over-precision can occur is in the process world. (Again, I know a bit about this.) When the time comes to write down processes, you have to make sure you don't write down too much. This example comes from the pharmaceutical industry, and I have to confess that I don't know what a "483" is, or if it's better, or worse, than a 482:

Companies can avoid 483s and warning letters if they evaluate their changes, validate them, and not have overly detailed SOPs for change control, according to industry consultants.

That was the advice of a 20-year industry veteran, addressing a Dec. 8-9 Center for Pharmaceutical Training/IQPC conference here, which was devoted exclusively to change control for makers of drugs and medical devices.

"In every audit I did with FDA, change control was a major thing they looked for, especially with water, HVAC systems and critical processes," said Kenneth Christie, senior director of consulting services at VTS Consultants in Westborough, MA....

"I have seen companies that have change control procedures so detailed that you knew after the first page that they were probably not in compliance. If it's that detailed, it would take its own staff to manage," Christie added.

He argued that when a company's SOPs for change control are too intricate, there are more opportunities for deviation. Christie recalled: "One company I visited had broken down their changes into so many details that detailed SOPs for change control, according to industry consultants."


The solution, of course, is to automatically initiate your changes via a cronjob. If they're executed on both the day of the month and the day of the week, then you'll show a lot of changes, which indicates busy-ness.

I'm kidding.

I think.

Sphere: Related Content
blog comments powered by Disqus