Remy Porter

Remy is a veteran developer who writes software for space probes.

He's often on stage, doing improv comedy, but insists that he isn't doing comedy- it's deadly serious. You're laughing at him, not with him. That, by the way, is usually true- you're laughing at him, not with him.

Common Variables

by in CodeSOD on

It's important to be prepared- but not too prepared. A common trap developers fall into is "premature abstraction"- trying to solve the general case of a problem when you only need to solve a very specific case.

Frequent contributor Argle sends us some very old BASIC code. The task was to convert this ancient language into C#.

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: