One of the clients for Rudolf's company was getting furious with them. The dev team was in constant firefighting mode. No new features ever shipped, because the code-base was too fragile to add new features to without breaking something else. What few tests existed were broken. Anyone put on the project burned out and fled in months, sometimes weeks, and rarely after only a few days.Rudolf wasn't too pleased when management parachuted him into the project to save it. But when he pulled the code and started poking around, it looked bad but not unsalvageable. The first thing he noticed is that, when following the instructions in the README, he couldn't build and run the application. Or maybe he wasn't following the instructions in the README, because the README was a confusing and incoherent mess, which included snippets from unresolved merges. Rudolf's first few days on the project were spent just getting it building and running locally, then updating the README. Once that was done, he started in on fixing the broken tests. There was a lot of work to be done, but it was all doable work. Rudolf could lay out a plan of how to get the project back on track and start delivering new features.It's about then that Steve, the product owner, called Rudolf in to his office. "What the hell do you think you're doing?"Rudolf blinked. "Um... what I was asked to do?""Three days and you just commit a README update? A couple of unit tests?""Well, it was out of date and meant I couldn't-""Our client is crazy about their business," Steve said. "Not about READMEs. Not about unit tests. None of that actually helps their business."Rudolf bit back a "well, actually," while Steve ranted."Next thing you're going to tell me is that we should waste time on refactoring, like everybody else did. Time is money, time is new features, and new features are money!"Suddenly, Rudolf realized that the reason the project had such a high burnout rate had nothing to do with the code itself. And while Rudolf could fix the code, he couldn't fix Steve. So, he did what everyone else had done: kept his head down and struggled through for a few months, and kept poking his manager to get him onto another project. In the meantime, he made this code slightly better for the next person, despite Steve's ranting. Rudolf eventually moved on, and Steve told everyone he was the worst developer that had ever touched the project.The customer continued to be unhappy. [Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!

One of the first things anyone learns about object oriented programming is the power of inheritance and overriding functions. Isn't it great that you can extend or modify the implementation of a function in your derived classes? Don't you wish you could just do that for every function? Aash's co-worker certainly does.

Many years ago, Sam was obeying Remy's Law of Requirements Gathering ("No matter what your requirements actually say, what your users want is Excel") and was working on a web-based spreadsheet and form application.The code is not good, and involves a great deal of reinvented wheels. It is, for example, Java based, but instead of using any of the standard Java web containers for hosting their code, they wrote their own. It's like Java Servlets, but also is utterly unlike them in important and surprising ways. It supports JSP for views, but also has just enough surprises that it breaks new developers.But let's just look at how it handles form data:

We all know that building SQL queries via string concatenation, and then sending them to the database, is just begging for fragile code and SQL injection attacks. But, what if the bad part is the "sending them to the database" part? Has anyone ever thought about that?Kris's predecessor has.

When discussing ternaries, we also have to discuss readability. While short and concise, they're in some ways too compact. But don't worry, Mark's co-worker has a wonderful simplification to ternaries. This representative line is a pattern used throughout the codebase.

Sebastian started a new job recently. Like a lot of "I started a new job," stories, this one starts with a 1,000 line class definition. What's notable about this one, however, is that most of that code is error handling. Now, you might think to yourself, "well, there's nothing inherently wrong with loads of error handling, if the problem calls for it.This code is getting posted here. Do you think the problem calls for it?

Kendall found some recently written code, and had to wonder, "Who wrote this crap?" Much to Kendall's disappointment, source control knew who wrote it: Kendall.

Today's anonymous submitter found some Java code which finds the largest value in a quartet of floats. Now, the code is quite old, so it actually predates varargs in Java. That doesn't excuse any of what you're about to see.

Today's anonymous submitter, who we'll call Sally, works on medical devices. As you can imagine, the development process for such devices is very strict. I mean, it should be, but we know that the industry has problems.Unfortunately for Sally, one of those problems is the tech lead on a project she is inheriting. Said tech lead is leaving, and Sally is coming on to replace them. The project is in C#, and Sally is the most experienced with the language, making her the obvious choice to step in.Now, the current tech lead had some concerns about the development cycle. You see, the whole process of writing code, compiling code, deploying that code onto hardware, and then running the code just took too darn long. If you wanted to iterate as fast as possible, you needed to skip some of those steps.

Lisa was working on a project she quite liked. The tech was cool, the problems being solved were interesting, and the team had a good working process. Company-wide, however, budgets were tight, and other projects were in much worse shape, so the project Lisa was on got put on pause, and her team was moved onto a different project.Someone wanted to make sure that functions which had large side effects were only called in the right places. Now, most of us might use some mixture of public/private, clear documentation, and maybe some key flags and error checking to ensure this was the case.This team had a... different approach.

Peter was tracking down some bugs, when he found code which looks like this:

The addition of nullable or optional types to mainstream languages was a net good. It doesn't completely solve the billion dollar mistake, but it makes it far easier to write safe code.For most of us anyway.Sam found this representative line, which shows how one of his peers understand nullable types to work:

Stefan S has recently joined the ranks of software developers, having taken on his first job as a junior developer. After a few months of on-boarding with Terry, another new developer, they're now both actually getting assigned real work on tickets that deliver new functionality.Stefan proudly pushed his first feature, complete with plenty of unit, functional, and end-to-end tests. After a little brushing up during code-review, it was merged along with a few "atta boys", and Stefan was feeling pretty good about himself.A few days later, he pulled the latest changes, and ran the test suite. And all of the tests he wrote suddenly failed. Stefan's stomach dropped into his shoes, and he struggled to think: "How did I mess up this badly?"Except Stefan didn't mess up that badly. A quick check on source control history showed that Terry had added some new commits- one of which "optimized" Stefan's code by adding a NullPointerException.Stefan was relieved, but annoyed. He opted to, in his mind, "be a bro", and not open a ticket that the rest of the team could see, and instead messaged Terry directly. "Your changes have broken functionality. You need to fix it."At 5:05PM, Terry pushed a fix, and messaged Stefan, "Tests don't fail anymore," then left for the weekend. Terry was correct, the tests stopped failing.(Names anonymized by Stefan)

Things weren't looking good for IniOil. It was the 1980s in the US: greed was good, anti-trust laws had been literally Borked, and financialization and mergers were eating up the energy industry. IniOil was a small fish surrounded by much larger fish, and the larger fish were hungry.Gordon was their primary IT person. He managed a farm of VAXes and other minicomputers, which geologists used to do complicated models to predict where oil might be found. In terms of utilization, the computer room was arguably the most efficient space in the company: those computers may have been expensive, but they were burning 24/7 to find more oil to extract.The CEO sent out a memo. "Due to economic conditions," it read, "we are going to have to cut costs and streamline." Cutting costs and streamlining meant "hiring a bunch of Ivy League MBAs" who had a long list of reforms they wanted the company to adopt. One of them was to force all the various business units to use internal billing and charge other business units for their services.At first, this looked like a good thing for Gordon. Their overhead costs were low- the IT team was small, and the VAXes were reliable, and the workloads were well understood. Billing out computer time was going to make all their metrics look amazing.Unfortunately, facilities also was a billable unit. And they charged by square foot. Suddenly, the IT team was paying through the nose for the computer room.What really stuck in Gordon's craw, however, was that it seemed like the computer room was getting billed at a more expensive rate than anything else in the building- it was about the same size as the sales floor, but was billed at double the rate.Gordon raised this with facilities. "That's not true," they said. "We bill by the square foot. You've got twice as much square footage."Gordon insisted that the computer room did not. He broke out a tape measure, went to the sales floor, took some measurements, then went to the computer room and repeated it. The difference was a matter of a few square feet.Gordon went back to facilities. "Your measurements are wrong.""They're square rooms," Gordon said. "How wrong could I be? A factor of two? Do you want to take the measurements?"Facilities didn't need to take measurements. They had drawings. And the drawings showed a room that was 80'x80'... and was 12,800 sq ft. Gordon pointed out how that didn't make sense, by basic arithmetic, and the facilities manager tapped an annotation on the drawing. "Raised flooring".Because the computer room had a raised floor, facilities was counting it as twice the floor space. Gordon tried to argue with facilities, pointing out that no matter how many raised floors were added, the actual building square footage did not change. But every business unit was looking to cut costs and boost internal profits, which meant "seeing reason" wasn't high on the facilities priority list.Gordon raised it up with management, but everyone was too panicked by the threat of mergers and losing jobs to start a major fight over it. Facilities said the square footage was 12,800, then that's what it was. But Gordon's management change had a solution."Gordon," his boss said. "Remove the raised flooring. Just rip it out."It was a quick and easy way to turn high billing rates into trip hazards and risks to equipment, but nobody was paying for risk mitigation and if there were any injuries because someone tripped over a cable, that'd come out of some other team's budget anyway.For a few months, the computer room was a hazard site, but the rent was at least cheap. In the end, though, none of it mattered- all the MBA driven cost "savings" weren't enough to stop a much bigger oil company from swallowing up IniOil. Most of the employees lost their jobs. The execs who owned most of the shares got a huge payout. And, well, the purchaser was interested in land leases and mineral rights, not computer rooms, so the VAXes were broken down and sold to a few universities. [Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.

Anton has the joy of doing PHP work using one of the more popular e-commerce platforms.Now, say what you will about PHP, its absolute mess of a root namespace has a function or class for just about everything. You want to split a string? We call that explode because that's way more radical than split. Want to join a string back together? We use implode, because that's the opposite of explode.Or, if you forget how to use implode, you could always write it yourself, which is what Anton found in the codebase:

The number of web applications which need to generate PDFs is too damn high, in my experience. But it's a requirement which continues to exist for a variety of reasons, so we just have to accept it.Derek was accepting of it, at least until he found this attempt to add ten lines of space between paragraphs.

Once upon a time, a company started a large React application. Like so many such projects, the requirements were vague and poorly understood, the management didn't have any sort of plan, and the developers didn't understand the framework. Once this inevitably started to go off the rails, all the developers were fired and then contractors were brought in, because that would be "cheaper".Spoilers: it was not. So all the contractors were fired, and a new round of hires were brought in. This time, though, they'd correct their mistakes by strictly enforcing Scrum practices to be "agile".This is where Gretchen entered the story.The code was a mess, and every feature was fragile if not outright broken. The project was overbudget and behind schedule before Gretchen even started. In other words, things were going great.Gretchen started with what appeared to be a simple task- fixing the fact that many text fields overflowed their bounding box and were thus unreadable. She dug in, and started going through the component code, which is where she found this:

As frequently discussed here, there are scientists who end up writing a fair bit of code, but they're not software engineers. This means that the code frequently solves the problem in front of them, it often has issues.Nancy works in a lab with a slew of data scientists, and the code she has to handle gets... problematic.

Let's say you had 6 different labels to display. There are many, many ways to solve this problem. Most of them are fine. Some of them are the dreaded loop-switch anti-pattern.Julien unfortunately inherited one of those.

Mark worked with the kind of programmer who understood the nuances and flexibility of PHP on a level like none other. This programmer also wanted to use all of those features.This resulted in the Base class, from which all other classes descend.Mark, for example, was trying to understand how the status field on a Widget got set. So, he pulled up the Widget code:

It's not brought up frequently, but a "CodeSOD" is a "Code Sample of the Day". Martin brings us this function, entitled StringOfToday. It's in VB.Net, which, as we all know, has date formatting functions built in.