Remy Porter

Computers were a mistake, which is why I'm trying to shoot them into space. Editor-in-Chief for TDWTF.

Nov 2022

Years of Success

by in CodeSOD on

Way back in late 2006, Cody inherited a Java application. Since launching in 2001, the application had been running in production without any notable problems. And then, one day, it suddenly started throwing out errors on some orders. And then, a little later, any time someone tried to place an order. This constituted a rather large issue, since processing new orders was vitally important for keeping the lights on.

The errors were validation errors, so Cody started by going to the line where the validation happened, and the exception was thrown:


Check Out This Legacy App

by in CodeSOD on

VisualBasic was… an interesting beast. The language wasn't great, and because object orientation was awkwardly bolted onto it, but it also was heavily integrated into Microsoft's ActiveX libraries (heavily object oriented), there were all sorts of interesting ways to break your program with it. Even better: it was designed to be easy so that "anyone" could use it.

Which leads to some of this code, from Dave. A number of years back, Dave was asked to try and convert an ancient VB6 application into something modern. Like all such conversions, the brief was: "make a new application that does exactly what the old application does, but nobody actually knows what the old application does because we never documented any requirements, just read the code".


Unit Test Coverage

by in CodeSOD on

One of the fastest ways to get promoted in certain environments is through attrition. When a key player leaves, someone needs to step up and take over their work, somehow.

Well, at Antonio's workplace, the tech lead on several projects abruptly quit. This sent the Project Management Office into a spiral, as that one developer's tasks were on every critical path on their Gannt chart. This four-alarm panic escalated all the way up to the C-suite.


Enterprise Streaming

by in CodeSOD on

Enterprise software development gets a bad rap, especially here, because "good code" isn't really a goal of an enterprise. Solving business problems is. And no enterprise is more enterprise than a government, and no government is more government than the US Federal government.

Which brings us to today's anonymous submitter, who wanted to keep up on current events in US politics. While watching some recent videos of Senate proceedings, our submitter got bored watching (as one would), they pulled up the browser tools. And that's where our WTF comes from.


SQL with no Equal

by in CodeSOD on

Relational Databases and No-SQL Databases take two key different philosophies, by and large. No-SQL is hard to talk about in broad terms, as it's mostly a set of unrelated technologies all solving the data storage problem in different ways. But we can still make some broad generalizations.

In No-SQL-land, we mostly store data the way we plan to query it. Ad-hoc queries are likely a bad choice, if they're even allowed. In RDBMSes, we store data according to a platonic ideal of normal forms, driven by the data in our domain. We can query the data however we like, using a language that only declares the data we want, not how to get it. Indexes and views and other behind-the-scenes structures make the query efficient.


It's Not That Different

by in CodeSOD on

We recently discussed the challenges of testing legacy code. Willy sent us some code from tests for a newer Java application.

Now, one of the main advantages, in my opinion, about unit-tests is that they serve as documentation. They tell you what the method does, and how it expects to be called. A good unit test is far better than a large pile of comments.


Switching Your Test Cases

by in CodeSOD on

Chris was given a program and told to improve it by adding tests. That was a good start to a terrible experience. Just getting it to build was a chore, as the build files had absolute paths hard-coded into them.

But the real problem Chris ran in to is that it's hard to write tests for something if no one knows what it does or why it does it. The application had no documentation. No comments, aside from commented out blocks of dead code. But comments aside, there was no other documentation. Which left Chris with methods like this to work with:


D'Tables

by in CodeSOD on

Wim works on a web app with a problem. Specifically, the error log is the fastest growing file on the system. Well, perhaps that's not the problem, but actually a symptom. Like so many applications, it's a PHP web app with a MySQL backend, and the previous developer made… choices.

$sqlisgt = "insert into ser_gen_tj values (4, '$type_juridiction', '$enr[23]', 'O')";

Hungry For an Education

by in CodeSOD on

An anonymous submitter from Hungary reached out with both some bad code, and a story behind it.

Hungary's school system runs on a software package called KRÉTA. The Sawarim$ hacker group felt that the software was badly designed and left millions of students personal information unprotected- so they hacked in to prove it. The company running the software responded in the worst possible way- by attempting to cover up the breach and pretending nothing ever happened. It's quite the news story.


The Parameters

by in CodeSOD on

As we frequently observe, code in scientific applications tends not to have the best code quality. And it's not hard to understand why: a researcher is frequently trying to take a wholistic understanding of a complicated problem domain and turn it into code. Software engineering, on the other hand, teaches us to break that wholistic picture up into little parts that we glue back together. The latter approach produces better code, but requires a lot of thinking about the structure of code, which is a whole layer on top of that wholistic understanding.

Which brings us to Plink, a C program Oliver R has had to work with. It analyzes genetic variance data. It also has a method with this signature:


A Null Mystery

by in CodeSOD on

The saying goes that debugging is like solving a murder mystery, where you are both the victim and the killer. This, of course, is a bit inaccurate, since we rarely are the only programmer working on a project.

Cole Tobin brings us a small mystery in C# today, though in this case, the mystery is- how does this even work?


Fixed the Bug

by in Feature Articles on

2020 was a rough year for everyone. Eventually, it will end, but as we drag through to the end of 2020.2, it's sometimes hard to remember the beforetimes.

Sometime in that long era before 2020, Marc's team patched a bug in their software. Like good developers, the patch included a unit test. They could prove that the test failed before the fix, passed after the fix, and happily closed the ticket and went on to different things.


What are you, Chicken?

by in CodeSOD on

My Steam profile doesn't represent the most active gamer on Earth, but in my time I put some pretty serious hours into the recent XCOM games. Each mission your squad goes on gets a procedurally generated name, and that can lead to some funny results just by itself (like "Avenging Avenger"). But, if you've put too many hours into the game, you might notice that every once in awhile, you see a mission with "Chicken" in its name.

Now, it's obvious that this is just a joke. Clearly an Easter Egg hidden in the code by a programmer. But Rich D picked through the UnrealScript which powers the game, finding the code responsible.


The Falling Dates

by in CodeSOD on

In the US, we "fell back"- that is to say we abandoned Daylight Saving Time and moved back to Standard Time, and I think the general consensus is that time changes are the real WTF.

So let's use this as a moment to look at some bad date handling code, an evergreen topic.


Nothing Wagered, Nothing Errored

by in CodeSOD on

Cassi continues the fight against ancient, creaky PHP code.

Today, it's particularly ancient- according to source control, it predates PHP 5.0 (and thus structured exceptions, and in this case may predate the current century). So the fact that this sets a pass-by-reference $errMsg variable and returns false on an error isn't the WTF in the code.


On SSL

by in CodeSOD on

Mark was trawling through the WordPress code, tracking down a bug in an extension, when he noticed this particular method for deciding whether or not WordPress is served via HTTPS or not.

function is_ssl() { if ( isset($_SERVER['HTTPS']) ) { if ( 'on' == strtolower($_SERVER['HTTPS']) ) return true; if ( '1' == $_SERVER['HTTPS'] ) return true; } elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) { return true; } return false; }

Not a WTF

by in CodeSOD on

Sometimes, I have to wonder if I'm the dummy. Today I want to take a look at two examples from readers that are pretty close to code I've written, and I'm left wondering: am I the real WTF?

meowcow moocat writes: