GRH inherited an application written by someone who is no longer employed with the company, as part of a project managed by someone who is no longer at the company, requested by an executive who is also no longer at the company. There are no documented requirements, very few tests, and a lot of "don't touch this, it works".

Well, it worked until it didn't. On a Friday before a long weekend, the application broke. As you might expect, it has a relatively small user pool, but is absolutely vital to the company's operations- if it fails, widgets don't get shipped and invoices don't get paid. So GRH got to spend that long weekend fixing the application.

In the bad old days of web development, you had to deal with the fact that there weren't really any standards, and you had to customize your code for different browsers. The "right" way was to sniff for which features were available, but the most commonly used way was to check the user-agent string and guess based on the browser name. Because of this, browsers started to keyword spam their user-agent, to pass these checks, which is why my browser reports as Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36. My browser of choice is a Chrome fork, and I'm running on an M1 Mac, so basically none of those things are true.

But let's look back at some code Lucas found, still lingering in a web app he maintains.

Validating your inputs is important, even when the sender is an API- in the land of JSON-based data exchange, we can't guarantee which keys exist without checking.

Philipp's team uses the "Runtypes" library to solve this problem. It lets them write code like this:

LK was browsing a local job site for a new position. The site was flaky, which lead LK to look into the code, and it looks like if anything, this job site should be hiring a new web developer.

function startSWBanner()
{
   browserType = "new";

   timenow = new Date();
   secs = timenow.getTime () / 1000;
   modnum = 2 * 10;
   range = secs % modnum;
   n = Math.floor(range / 10);
   urlArray = new Array(2);
   banArray = new Array(2);
   altArray = new Array(2);
   popupArray = new Array(2);
   urlArray[0] = '/cgi-bin/banner_track.cgi?banner_id=2627';
   banArray[0] = '/rot_ban/v2lbanner.gif';
   urlArray[1] = '/cgi-bin/banner_track.cgi?banner_id=4245';
   banArray[1] = '/rot_ban/ir35_banner.gif';

   if (browserType == "new")
   {
        document.swbanner.src = banArray[n];

      startThread = setTimeout("rotateSWBanner()", 10000);
   }
}

If you want to configure a Java application, the standard way to do it is to use the Java Properties class. This class wraps around a simple, text-based file format (or an XML file, if you're into that) that allows you to store key/value pairs. It helpfully inherits from the HashMap class, letting you interact with those key/value pairs using a well understood API. The file format handles all the details of encoding and managing things like multiline strings.

So you could just do that. Or, you could do what this senior dev with over a decade of experience did.

Code reviews are an important part of development processes, but sometimes, some developers manage to sneak around the process. That was the case with Orien's team, where most of the team were constantly checking in with each other, doing peer reviews, and trying to collaborate on a rather gigantic Perl codebase. One team member, on the other hand… didn't. Management wasn't interested in pushing the issue, so this developer got to do their own thing.

And then the developer left. Over the next thirteen months, bug after bug started cropping up. Minor changes that should have been easy would unleash a ball of spaghettified nonsense that was impossible to debug but also emphatically didn't work. Things got so bad that the entire team needed to stop doing any new development for three months, and just fix bugs and refactor.