Many European nations require their citizens to serve in the military. For those not ready for that Starship Troopers-esque future, most of those nations offer a civilian alternative. In Finland, this is called “siviilipalvelus”.
Siviilipalvelus is what brought Sampo to a small sub-department of the Finnish Treasury. He had programming skills, and they had a programming problem. They had an application which was older than Sampo, and at this point no one knew what the original requirements were, nor whether it met those requirements. There were half a million lines of code that were ported across many environments, and not nearly enough eyes to review them.
Sampo’s first stop in the process was the business rules module. The only documentation was a simple “one-box” diagram, which explained that a pile of linked-lists went in, and a report on pension payments came out. The intersection of bureuacracy and legacy code meant this was a spaghettified mess. It cost 50,000 €/year to keep the system from falling over and crushing a passing pedestrian. Since the 100 page report was only run once a year, the total bill was a thrifty 500€/page.
Eventually, Sampo had to ask: where did these linked lists come from? “You’d have to look at the parser module,” his supervisor said. The parser module took a large pile of strings as its input, and converted them into linked-lists of structured records. Since file structure had changed as the system was migrated from platform to platform, the module contained a great deal of code like: “If character 12 is ‘Q’, then characters 13–50 are the account number, but if character 12 is ‘F’, then characters 13–30 are the province name (truncated) and 30–50 are the old-style account number.”
After tracing through that code for a few weeks, Sampo had a new question. Where did the strings come from? “From the file reader module,” his supervisor said. “Where else?” The file reader scooped up flat-files from a directory and cranked through them. To prepare the files for parsing, the reader did some “pre-parsing” to find IDs and resolve what were essentially foreign key relationships. It joined the files using its own implementation of nested-loop joins. It was as time consuming as you might imagine, but since this report was only needed once a year, performance wasn’t a concern.
But where did those files come from? “They’re a direct data-dump from Oracle tables,” his supervisor said. “There’s a PL/SQL extract module that converts them to flat-file records.”
That left Sampo with one more question. “Is there any reason we don’t do this process in SQL?”
“Yes.” His supervisor reached under his desk and extracted a dusty binder labeled “Treasury Programming Standards Manual: 1976 Edition,” the most recent version of their programming standards. “Due to the highly variable and proprietary nature of database formats, all data-processing will be done in flat-files consisting of fixed-length fields,” he read. “No direct access to databases is permitted.” He closed the binder with a puff of dust. When the cloud cleared, he finished, “And we’re not reimplementing it anyway. Go finish your audit.”
In the end, Sampo and his peers did finish the audit. The application did not meet the specifications, although it was still fuzzy exactly what they were. Huge sections of it needed to be reimplemented, and Sampo’s team was responsible for reimplementing it. Unfortunately for them, Sampo’s supervisor was responsible for ensuring they adhered to all of the department’s programming practices.