Trevor D. recently got a job at a company that has provided all of Europe the means to ship dangerous materials for decades. He wasn't specific about which dangerous materials they deal with, so I'll speculate: radioactive, flammable, toxic, corrosive, or biohazardous chemicals, and maybe bees and cobras.
Whatever these dangerous materials are, Trevor maintained an application that could print labels for whatever dangerous goods were being shipped. These labels would list why the contents were dangerous and any necessary precautions for handling them. For instance, chemicals that can explode get a "combustible" designation, biohazardous materials get the logo of defunct New York old-school hardcore band Biohazard, and cobras and bees are labeled "warning: this package is full of goddamn cobras and bees!"
The strange thing about this label-printing application is that it doesn't actually print labels. Instead, it serves as a wrapper for commercial label printing software. The application Trevor maintained just tracked shipping information and the designations that would go on the labels, and provide that data to the actual label-printing application. This application would populate a standard template and spit out a label.
It's really a pretty simple process; the first application did the logging, while the third-party printing application did the printing. So, naturally, it resulted in a pretty simple solution. Ha! Just kidding, of course it didn't!
The design team wasn't as much a team as a series of sequential programmers. It was originally developed by a guy who quit, development continued with a new guy until he quit, ad nauseam. And like the rings of a beautiful, majestic redwood, chunks of code bearing each fallen developer's coding style left unique impressions in the code.
The first iteration of the software was built to use an archaic piece of label-printing software, along the lines of a LabelPrint Pro! that you could buy in the $1 bin at Wal*Mart. It ran from an Access database, as it'd be used mostly by people who only had Office and a few other apps on their systems. Still, it was an absolute WTF of a database; no relationships, product information split between no less than five different tables, and a useless, unconnected LPNUMBER table. It apparently provided information to the user, even though all data in LPNUMBER was duplicated elsewhere in the application. All data were stored in either a TEXT or MEMO column; there were no NUMBER columns in use anywhere.
Work on a new version of the database was mostly finished by the time Trevor started at the company. He was tasked with importing users from the old database to the new one. It was almost a step in the right direction, but the new database was just as bad as the original.
In the new database, relationships were still unenforced, but at least product information was now in one table instead of five. The new version of the application was designed to support 14 languages, which added 13 more tables to the database. The non-English tables were missing a lot of data and had to be filled with blanks.
The unconnected LPNUMBER table from the old database was removed, too, which was encouraging. However, it had been replaced by another unconnected table containing every bit of personal information the company had on its customers. Why they provide every bit of information they had about every customer to every customer is a mystery.
Trevor is still hacking away at a VB.NET application to combine the data between applications. He's got a lot to deal with; tables with no unique keys or referential integrity, working entirely with TEXT or MEMO columns, and preserving the new data. Thankfully, work has begun on the next iteration of the software, using a new SQL database. Trevor's team has assured him that it'll be a significant step forward for the application, just like the last major update.