Far away across the Atlantic, in the mythical land of Eastern Europe, where the sun don't shine and wild beasts roam the roads, lies a little country called Poland. Known in the world for its cheap manual labor and fondness for strong alcohol, it has for years been the butt of every national joke in almost all parts of the globe. But people here (or at least those who haven't run away yet) have been working hard to combat those pesky Eastern Bloc stereotypes, and as such, the country has in recent years seen a lot of social and technological progress. That last one, of course, comes with one notable exception: the government sector.
Obviously, most countries' governments have a love-hate relationship with technology- but the Polish government invariably tends to be special. Between national-level exams being leaked by putting them in an unprotected folder with directory listing turned on, and the Social Insurance department buying 130,000 floppy disks in the year 2008, our government's technological proficiency has us ranking slightly below Elbonia. And so, when it was announced that the next local elections would be far more computerized than any of the previous ones, everyone trembled in fear.
The election day came and passed. At that point, everything was still done using pen and paper, so nothing had a chance to break. But soon after, the Polish Electoral Commission announced that the election results might be "slightly delayed". At the same time, someone in one of the local commissions with access to the software used in vote processing noticed an odd .pdb file with debugger symbols in the program folder. Being a good citizen, they immediately took a decompiler, restored the source code in full, and put it on GitHub for everyone to see.
Now, the following part might not be for the faint of heart. Here's one of the most notable source files from that GitHub repository.
This particular piece of code had one simple task: taking XML files with election results and generating an HTML file with an official election protocol. There are many ways to approach that task. The more clever people would probably go for an XSL transformation. The slightly less clever ones would use an HTML template and fill it with data. This code, however, does not try to be clever. It aims to keep things simple, using an old and trusted way to achieve its goal:
this.header = "<!DOCTYPE HTML><html><head><meta charset='UTF-8'><title></title><link rel='stylesheet' type='text/css' href='" + System.IO.Path.GetDirectoryName(Application.StartupPath) + "\\tmp\\printTmp\\css\\styl.css'>”;
And it’s all downhill from there. Down a very rocky hill, full of cliffs and jagged edges, whose exact shape can be seen by scrolling down the GitHub page. After just a bit of introductory code comes the getProtocol
method- a massive, 2000-line behemoth full of foreach
es, if
s, and else
s iterating over the XML document and nested so deeply that some lines simply fail to fit on the screen.
Other WTFs include, but aren’t limited to:
- standing on the shoulders of giants by porting good old
On Error Resume Next
in the form ofcatch (System.Exception) {}
- taking the lesson from 90’s web designers with
response += "<br><br><br><br><br><br><br>”;
- taking
StringBuilder
s to be too 2000’s and using good old performance-murdering string concatenation - trying to create a directory and, if it doesn’t exist, catching all sorts of exceptions that can occur in the process, showing a warning to the user, then writing to the nonexistent directory anyway
- fixing up broken CSS by adding a script to the page that sets up magic number margins after the page is loaded
After that leak, the news a few days later that the results will be delayed even further came as no surprise to anyone even remotely tech-savvy. Oh, and the part of the code that failed? The protocol printing module, a.k.a. today’s Exhibit A.