The December 2022 issue of IEEE Spectrum is here!

Close bar

Well, you may not be able to smile at the Virginia Department of Vehicles when getting your driver’s license, but at least you can get one. In Montana, they had to close their motor vehicle offices for a couple of days in early June to walk-in traffic in an attempt to fix their newly installed, $28 million Montana Enhanced Registration and Licensing Information Network (MERLIN) software system.

Since MERLIN was installed in April (two years behind schedule), Montana county treasurers "have been reporting operating problems causing delays in processing motor vehicle-related requests involving registration renewals, title work and license plates," says a story in the Great Falls Tribune.

It also looks like there are some human interface design problems, as well. The Tribune story states that "clerks must navigate through six or seven windows. Once the clerks are at the final window, it can take an additional 10 minutes before the printer acknowledges the transaction."

Montana hired Bearing Point  to develop the MERLIN system, which is based on software, originally developed by Colorado-based Archon Technologies, Inc., that is successful used in Iowa. Bearing Point entered an exclusive teaming relationship with Archon in March 2006 to offer the software; Archon was then bought by 3M in July of 2006.

Montana government officials blamed current difficulties on a lack of "knowledge transfer" between Bearing Point and 3M (after almost 3 years of an exclusive teaming arrangement?) as well as "basic problems in the architecture" which stress testing didn't uncover, according to another Tribune story.

Last week, Larry Fasbender, deputy director of the Justice Department that oversees the Motor Vehicle Division told a Montana legislative oversight committee that Merlin was much improved from the beginning of the month.

"As of this morning, we are having very few problems with the system - very few complaints" Fasbender was quoted as saying.

However, Montana county treasurers don't necessarily agree.

One country treasurer said that they were not processing titles as quickly as they did before Merlin was rolled out. Renewals that used to take 15 seconds now take a few minutes, and vehicle title transfers that took 15 minutes under the old system can require up to 2 hours to complete using Merlin.

The treasurer said that last month it took about two hours and 15 minutes to process a vehicle title transfer, so technically, there has been some improvement in system performance.

Still, the treasurer said, "I think Larry might be glamorizing a bit."

"Glamorizing" - what a nice way of putting it.

According to this Montana state document which provides recent background on the project,

"The Motor Vehicle Division has been in the process of re-engineering business processes and development of a new automated information technology system. This effort has been known by several names, including HB 577, HB 261 and TEAM 261.The project timeline dated October 16, 2008 indicates that the project was initiated in December 2005 and is scheduled for final acceptance in December, 2010, a full five years after initiation, three years after it was originally estimated to be complete, and nine years since the initial legislation authorizing the incurrence of debt for this purpose (2001)."

"The department indicates that the [MERLIN] system is expected to have a useful life of 20 or more years."

That is, if Montana can get MERLIN to cast its spells correctly.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less