Why they are needed

Why are written-down standards and procedures needed?

There is one obvious reason. Some things can be done in various different ways, and having one uniform way of doing things in one company or a group helps to maintain uniformity. This allows everyone within the company to do it "the Merce way", and makes it easier for experienced team members to know what to expect.

This was the obvious reason. There is unfortunately a second reason which is more disturbing, and sometimes more serious.

We have seen many instances of our intelligent and competent employees behaving in a way which others may feel defies logic. They act in a certain way which they consider "obvious" or "natural", but others may not agree. In doing so, they break processes and weaken the power of major infrastructure or practices, things on which any sustainable company is built. They sometimes cause serious financial loss to the company, usually by wasting resources, sometimes by loss of information.

When we look at these incidents, we realise that we had assumed some things to be "common sense" or "obvious" but evidently other intelligent people did not think so. I see no defence against this difference of perspective, other than codifying some of these things into written-down S&P notes.

Some examples of these disturbing incidents where "obvious" was not very obvious:

• Use of CVS: We have a CVS setup running on our office servers. CVS is a version control system. Any files in CVS are expected to be checked into CVS if they are modified.

  I discovered that an important semi-legal document issued to every employee in separate edited versions, had been checked out of CVS, edited freely in home directories of various employees, and had been printed and issued out, without being checked back in. This had been done for a period of about two years, in spite of the document carrying clear CVS log comments indicating that each edited version till 2005 had been checked back into CVS for the record. See the log here [1] -- these lines were embedded in the original file for all users to see. We had mistakenly assumed that any officer editing the file would see its presence in CVS, see these log comments, and would know that each edited version needs to be checked into CVS. We were wrong. Between 14 Oct 2005 and 29 Aug 2007, no one checked in any changed version, though perhaps a dozen versions were created and officially issued.

• Source in CVS: Our internal CVS repository contains an archived copy of all source code we develop for all customers, unless expressly prohibited from doing so by any confidentiality agreement.

  Yet we discovered that a major and complex project has been submitted to a customer for acceptance without checking in any copy of the file tree into our CVS repository. This was done by our most experienced project manager and technical member, who had helped set up our CVS usage processes. And this failure was discovered more than 15 months after the software had been submitted to the customer for acceptance. We had mistakenly taken it for granted that all software would be checked into CVS before being submitted to our customers.

• Office LAN architecture breakdown: Our office LAN has two segments, separated by a firewall. One segment has "production" information, including confidential accounts and files. The other is a "lab" environment where no security rules can be applied. A firewall is necessary between the two for obvious reasons. We were under the impression that the presence of the firewall, plus the clear segregation of the LAN into two subnets, would communicate to all officers that the subnets need to be kept segregated.

  Evidently, the physical infrastructure and obvious segregation was not sufficient to communicate the need to continue with this practice. When we moved office, some officers (some of our more competent and intelligent ones) set up computers in a mixture such that the firewall became redundant. Anyone in the "lab" environment could simply change the IP address of his computer to connect himself to the protected "production" subnet and completely violate all security protection mechanisms there. Usually, security restrictions are bypassed because of a need for convenience. Here even that reason appeared not to have been present.

  We have no indication that any security intrusion was attempted or even contemplated. But the breakdown of a well-thought-out and carefully constructed network architecture for no good reason, and the potential security risks to company information, was very disturbing.

• File name silliness: We usually discourage file names with spaces in them; they may break carelessly written shellscripts which operate on files. And in most environments, file names have a structure with a prefix and an extension, separated by a period character. Common file types like MS Excel files have names like something.xls. The filename extension is important; some processing of files sometimes depends on it. We had never felt the need to demand filename standards for ordinary files in everyday use; we had assumed that people would automatically follow widely accepted conventions about filenames.

  On 2 August 2007, one of our engineers sent a mail to Zodiac (a copy probably can be found in the support newsgroup) with a spreadsheet file attached. This file had the name

  zodiac setup....xls

  It had four periods in the filename. When asked why he had created a file with this name, he responded that this was the name he had been given by an earlier copy, or some such completely inconsequential reason. We then learned that even filenames for ordinary everyday files need to have corporate standards.

In each case, we realised that we do not have any really good way to ensure that carefully constructed infrastructure or processes do not get broken down this way in future. The only solution we could think of was written-down standards and procedures. We have always felt that unnecessary bureaucracy is destructive, specially in a small, very personal company culture. But the inadvertent and unnecessary damage we have seen in our company makes us believe that bureaucracy and process rigidity may be the lesser of the evils. Hence these documents. The office LAN architecture breakdown incident led to the creation of the written IS Security Policy [2], for instance.