Four months ago, an old friend and I were discussing the IT situation at the DMV. It was in the news then, as now.

She mentioned that one of the issues was related to printing vehicle registration tags. I suggested that those tags were nearly obsolete, that any camera that could read a license plate could look up the registration status of the vehicle in near-real time. In this post, we will riff on this wacky idea and introduce several concepts for further consideration.

The first thing that needs to be understood is that it is way easier to suggest innovation than to deliver on it. In my experience, too many innovators have wacky ideas with no idea of what is required to implement them. These sort of ideas are not as useful as they should be.

The second thing, and one of the threads behind all of these posts, is that often, implementation is easier and less costly than you might think. As in my previous post, ease may come from the reuse of open-source components. Here is a link to an open-source image recognition system trained to read license plates: SOD — An Embedded, Modern Computer Vision and Machine Learning Library. Here is the better post: How I replicated an $86 million project in 57 lines of code. The title says it all. In 57 lines of code, over a weekend, a programmer developed the core of an application that could be implemented as a minimum viable product in a police car that recognized license plates and performed a lookup on the vehicle registration database.

I will leave you to read the article, but in case you do not, let me point out, as the author does, that the scope of what 57 lines of code provides is far less than what is provided by the $86 million product. Still, if a contractor could deliver a working prototype in a week for $200 an hour … for $8,000 … what could be accomplished with the $85,992,000 remaining?

The point is this: Silicon Valley companies do not deliver 10X or 100X more value per programmer month than what we see in government programs because their programmers type 10X-100X faster. They see these dramatic improvements because they reuse open-source code publicly published in repositories such as GitHub, GitLab and SourceForge. They reuse pieces of open-source products from the Apache Foundation.

Note the tangential point: Using open source does not always, or even usually, mean using open-source products. It does not have to suggest replacing your proprietary database management system with PostgreSQL. It does indicate that you need to look for components that may be reused.

In the previous post, I suggested that building large applications such as those required by the DMV is no longer difficult. Scale comes naturally from implementing cloud-native applications. Now I am suggesting that through the use of open-source components, these problems, which used to be extremely hard, become more tractable.

In the first post, I suggested that we must develop systems that are designed to change. I will come back to this often. Let me leave you by asking: If we develop a system today that reads license plates via a camera with image detection software and displays the results on the console of a police cruiser, will we throw it away when, with five or 10 years, cars will be able to broadcast their license over Wi-Fi, and the camera reader will become obsolete?

We should build a system that can accept vehicle IDs from any source and display the results of the lookup. To go further, when cars reliably broadcast their ID over the air, why are license plates necessary? Vehicles can transmit their Vehicle Identification Number (VIN), and we can check registration that way.

Change is coming. Modernization is doable. When we modernize, we have to develop systems that accommodate change. 

IT veteran Rob Klopp's background includes having served as CIO of the Social Security Administration during the Obama presidency. He writes opinion pieces periodically for Techwire and blogs at the federal CIO website, CIO.gov. The views expressed here are his own.