My first State of Michigan job was checking the output of a new computer program. That program’s clever moniker was Computer Decide, and it identified drivers whose record suggested they needed intervention–which might be counseling, a restricted license, a suspension, or some other sanction. The program detected patterns in driving records, and was probably considered cutting edge in 1977. I joined several senior clerks in the Review Unit, and was clearly playing out of my league. But that’s some other post’s discussion.
Computer Decide was the last, and most complex, piece in the Department of State’s initial drive to computerize its DMV record-keeping. It was also among the Department’s first serious forays into computerizing the business workflow–only a small step, mind you, but a necessary foundation. Our programmers would later build a system to schedule hearings on that base, and different coders would automate other processes. Some of this automation took place on the mainframe, of course, but we’ve since accumulated an array of systems on a variety of platforms. Many of those are now in their second or third incarnation.
But to keep today’s yarn manageable we’ll limit this discussion to Computer Decide. An unavoidable reality of DMV life is that the Legislature rewrites the Drunk Driving laws every two or three years. The Legislative package typically includes well-intended amendments to other driver licensing laws. The lawmakers rarely give much thought to the new act’s impacts on the driver’s prior record, nor to their predecessors’ attempts to improve traffic safety. This routinely gives rise to odd interactions which need to be implemented in the workflow–and written into the programming supporting that workflow. A side effect is that Computer Decide has grown quite complex. Mainframe programs supporting other departmental operations have similar issues, and have grown similarly complex.
By the late 1990s it was clear that this complexity had become a problem, and that the foreseeable retirements of the COBOL programmers supporting that complexity would, eventually, create a crisis. Maintaining the existing code had become their main occupation, and getting non-legislative initiatives off the ground had proven virtually impossible due to a shortage of expert programming staff. Equally worrisome was our vendor’s evident plan to reduce their corporate dependence on their mainframe product, which was the heart of both their business and our data store. Departmental leadership, recognizing these issues, began exploring ways to move to a new, less problematic, platform.
Where those explorations led is some other post’s discussion, friends. Not sure when I’ll feel comfortable sharing that story.
Ate breakfast recently with one of those COBOL coders. Mostly we had an old-friend chat, but we briefly discussed her replacement’s lack of experience with the system he’d inherited when she retired. That crisis is here….