Resurrected documentation of US Courts development

As I prepared to leave the US District Court in Detroit for Purdue, I knew that it would be important to leave a very clear trail of documentation for my successor. Ours was a pilot court in the judiciary's new TCP/IP internetwork, and one of our server OS vendors had just transitioned to pure HTML online documentation in their latest release, so I had the perfect opportunity to create comprehensive docs of our local development in that form, converting docs written earlier in other formats and writing new material.

The pages linked here represent much of that documentation, unchanged from its form at that time. Because it was developed in the normal course of civilian US government employment, it is not subject to copyright, and the IT environment in the courts has changed sufficiently since then that I have only omitted a few pages out of any concern for their sensitivity. Most of the dead links you will find are the links to the commercial OS's online man pages and admin guide, and those to the CGI gateway I had developed to the court's SCCS versioned sources.

The man-page sections included here were locally developed—so, for example, the section “unify” is not reproducing man pages from our DBMS vendor, but pages documenting our own scripts pertaining to the DBMS.

Sometimes you have to hold to a long-term vision

A strategic goal for the Court throughout my tenure was to develop a system for public access to case information that would integrate live cases in our current case-management system, older cases that had been archived from that system, and even older legacy cases from a defunct central system that had been maintained in DC.

This document describes how we got there. How many surprise discoveries and detours can arise in such a project, and how can they be accommodated? The story is all here.

Update: that document carries the story to 1996, when I left the Court for Purdue, and was left for my successor, whom I did not have a chance to meet. Ten years later on a return visit, I caught up with the Operations Manager, who related the following epilogue. In the course of those ten years, the case-management software for which all of my development had been done was replaced by the US Courts' current (still, as of 2013) CM/ECF system. At the time of the switch, my successor announced that there would be no way to carry over to CM/ECF my system for seamlessly accessing archived and historical as well as live case data. Before anything was lost, his counterpart in the Bankruptcy Court, housed in the same building, agreed to take a look, and found my work clear and adaptable enough to have a working demo in CM/ECF the next morning. So the work survived, and the Eastern District of Michigan's public-access system continued to provide one-source access to live and historical cases, at least as of 2006 and, as far as I know, to this day.

The story leaves me grateful to the Bankruptcy admin (whose name I didn't learn), and reminds me how heavily the lasting value of any significant work depends on factors in and out of my control. It is in my control to make the work clear and document it well, and yet even with the best effort, much hangs on whether the next person will make the effort to understand and preserve whatever is valuable in it.

And sometimes there are interruptions

The following describe a few interesting diagnostic opportunities that came up. The DBMS we were using was designed in a way especially likely to produce diagnostic opportunities. These docs were written to help build the successor admin's arsenal of diagnostic techniques.

• Successful updates that don't?
• Duplicate primary keys in a regular pattern?
• Death by termcap?

$Id$