AntiPattern Name: Electronic Pickle Jar
Type: Design/Document/Configuration management
Problem: Need to implement a mechanism for sharing content (documents, source code, etc.) and allow for that content to be versioned.
Context: Almost any business organization that does projects. Code development is most certainly included.
Forces:
- The desire for lightweight configuration management tools that don't "get in the way" of users
- The desire to avoid spending megabucks on something like ClearCase (and the necessary support infrastructure -- servers, networking, admins) needed to run it.
- A belief that employee empowerment should include removal (or failure to implement) internal controls, particularly on document handling procedures
- In particular, a belief that no task an employee might want to do in the course of normal business should require intervention or assistance by a system administrator.
Supposed Solution:
Use a globally-writeable shared drive as a document repository. Access to documentation (including write access) is broadly granted. Version control, if it exists, is ad-hoc -- either depending on applications (i.e. MicrosoftWord) for version control, or use of DateStampedFilenames to track multiple versions of the same document. A tool like RCS might be used for source code. No configuration management support is provided (unless ad-hoc scripts are written for the purpose). If documents need to be organized somehow; the underlying filesystem topology is used.
Resulting Context:
For small-scale operations, this can work, provided:
- Backups are made on a regular basis in case someone screws up.
- All employees accessing the pickle jar can be trusted.
- Manual procedures regarding versioning and change control are followed ("if someone has the document open, then make a copy", "when you save, save under a new name with today's date")
Many people like this because:
- It's fast -- no cumbersome middleware gets in the way. All file access operations are directly to the OS filesystem.
- No need to pester administrators with problems -- anybody can figure it out and/or set it up.
However, lots of things can go wrong:
- Dependent on that one machine (often times, the ElectronicPickleJar is on a user's machine), which may or may not be backed up regularly.
- Failure to follow procedures can easily result in lost data.
- Unable to revert to an earlier configuration, or to associate the same "generation" of disparate documents.
- Does not support queries (in general).
- Does not scale well. When you have a medium-sized organization (or larger!) with numerous products in different phases of development, anarchy frequently results. Nobody can find anything
- Old versions can easily get lost or forgotten, or be mistaken for current information.
Design Rationale: [rationale]
It's cheap, fast, and easy to set up.
Related AntiPatterns:
ElectronicFortKnox?. What is often found at large companies, or in reaction to a major catastrophe traceable to a failure of the ElectronicPickleJar.
Applicable Positive Patterns:
AntiPatternCategory: [classify it]
Also Known As: [other names]
Notes:
The name "pickle jar" was common slang in some environments for a disorganized paper filing system -- rather than keeping documents in a neatly-organized file-folder; they were just stuffed into the equivalent of a pickle jar for storage.
The "pickle jars" referred to are probably the large, multi-gallon jars used in the past for storing and displaying pickles and other items for sale in taverns and general stores. It's easy to put a pickle in such a jar, somewhat harder to to retrieve a pickle, and downright difficult to retrieve a particular pickle. Like their filing system counterparts, pickle jars are optimized for writing but not for reading.
A DevilsAdvocate might point out that the ElectronicPickleJar might be appropriate then for those organizations wherein documents are written (in order to satisfy some policy or procedure) but never subsequently read (except possibly by an auditor who is verifying compliance with the procedure). Use of an EPJ in this circumstance optimizes for the common case (writing), and most auditors provide sufficient advance warning of their arrivial so that the necessary documents can be retrieved from the jar in a timely fashion.
Of course, production of useless documents itself strikes one as an AntiPattern.
Examples in the Literature:
Examples in Practice:
- Many startup companies, with small staffs, limited resources, and little data to manage, fondly use ElectronicPickleJars. Use of seed money or venture capital to buy things like ClearCase is frequently seen (both by managers and by lenders) as an extravagance, no matter how useful.
- Even companies who have proper source control will often have an ElectronicPickleJar set up in the form of a large network directory which has folders for various projects and generally subfolders under those projects for the Engineers themselves. Employees are encouraged to put works in progress on this network folder which is backed up daily. Once a document becomes official, it gets put into some form of source control, but until the formal review, it stays on the network drive. It's generally a combination of EaseOfUse? where one doesn't have to go through the extra steps of checking out and checking in files (often with sizable delays, and with little hiccups like Microsoft Word refusing to save a file which was opened while it was read-only, even if it's been checked out since) and that sometimes the entire repository goes to the customer and the company doesn't want those ugly early drafts to be part of the delivery.
What's the alternative?
- Decent configuration management tools; there are many OpenSource examples which will suffice.
- Can anyone be a little more explicit? I'm living this AntiPattern, but ClearCase is not going to be a viable alternative.
- SubVersion, etc.
- I have used darcs with tools that produce OpenDocumentFormat files. Since ODF files are zipped first, you probably need to manually unzip them for maximum benefit, so as to reveal their XML components, since tools like Darcs and SubVersion assume a textual file representation for maximum benefit. -- SamuelFalvo?
- Lightweight methodologies which don't require steaming piles of documentation.
- Versioned wikis!
CategoryAntiPattern
Electronic Pickle Jar