The story begins with To CATCH a Thief
Part Two: Sneaker Net
The CATCH database that I developed for the Philadelphia Police Department was a tool of empowerment. My area of responsibility, the Latent Print Section, was involved in many high-profile cases. Yet, the bulk of our success came from closing hundreds of cold cases over the years. My immediate supervisor was empowered to tackle decades-old homicides. As more time was freed up by the automation of mundane record-keeping, my squad was able to devote more time to working with the Automated Fingerprint Identification System (AFIS.) After all, that was where the true expertise lay. It was a snowball effect: more solved cases begat more suspects in other cases. It was mind-boggling.
With the glowing success of CATCH, the Police Department became my digital playground. Officially, I was a Fingerprint Identification Supervisor. In actuality, my Commanding Officer and I created many mutually beneficial opportunities around both CATCH and my willingness to build databases for other units. In the beginning, I was mostly helping people to convert spreadsheets into databases. Later, I developed databases from scratch, based on what was needed.
The common denominator in every single one of the databases was the Police Identification number – PID. This number was like a Social Security Number for fingerprint cards. It didn’t matter whether the fingerprints were from criminals, police applicants or any of the civil record-keeping units such as gun permits. The PID was unique for each set of fingerprints.
Well, that was the general idea. The truth was that far too many duplicate records existed in the various files around the Police Department. This presented both a challenge and an opportunity for my database development efforts. I met this challenge by developing an informal information exchange between each of the units. The medium of exchange was writable CDs.
In a nutshell, my work computer became the clearinghouse for every PID. The reason was simple: we were the ones who needed to match PIDs to fingerprints and, because of the need to eliminate fingerprints of investigators, we were more likely to match against civil prints. So, with a single point of data entry, I was able to generate updated records for any unit that needed them.
At the time, the IT staff at the Police Department was very stingy about granting access to its internal network. My unit was not part of any network. I had to burn CDs for backups, so it was natural to turn to CDs for my ad hoc database network. Hence the name, “Sneaker Net”, an endearing term that refers to running around from computer to computer with a disk.
The key to making the Sneaker Net efficient was automation. Creating CDs was beyond the scope of the database program, so I used good old DOS batch files to copy whole databases to CD. The beauty of this approach was that other users merely had to insert the CD into their computers and run the database that I had made. That database, in turn, read the database from the CD and, within minutes, everyone had the same set of records.
I learned some valuable lessons and continued to hone my service philosophy. In addition to relieving tedium, my goal expanded to striving for continuity in work experience. I didn’t want to force people to adapt to my ideas of how a task was to be completed; I watched how people worked, asked them for suggestions and made recommendations. The databases were designed only when the people were satisfied that I knew what they needed. Here is a replica of a document I distributed with one of the databases:
Of course, working for a paramilitary institution meant that, despite my best intentions, sometimes people were forced to do things in a manner consistent with Department policies and directives. Within those constraints, however, I did manage to keep most folks happy.
Thankfully, the Sneaker Net regime was short-lived. IT couldn’t ignore us forever and we finally got connected. I spent the remainder of my career converting Sneaker Net to the standard practices. This meant that we all shared a common database. Life became simpler.
In 2004, I left the Philadelphia Police Department for the greener pastures of Virginia. I ventured into other endeavors but, soon enough, there came an opportunity to build an automation system. I was about to get an immersive education in Microsoft Excel and massive spreadsheets. Unbeknownst to my teachers, they were about to get an immersive introduction to my brand of automation.
In Part Three, check out my struggles with enhanced 911 services, cable networks and a little thing called DDE.
|The ParserMonster story is a time-mellowed account of my adventures in programming. The experiences led to the creation of ParserMonster, a framework for automating text-based tasks.|