The Daily WTF

Matt has plans for the next few years: dealing with the "inheritance" of some legacy systems.They're written in VB.Net, which isn't itself a problem, but the code quality leaves just a bit to be desired.

Jesse had a "special" co-worker, Rupert. Rupert was the sort of person that thinks they're the smartest person walking the Earth today, and was quite happy to loudly proclaim that everyone else is wrong. Rupert was happy so long as everyone else was ready to bask in his "genius".Fortunately for Jesse, Rupert left, because he'd received a huge offer for a senior developer role at a different company. Everyone at Jesse's company privately chuckled about it, because this is the kind of code Rupert's genius produced:

Virginia N (previously) needed to maintain some authentication logic. The actual rules for authentication weren't actually documented, so her choices were to either copy/paste some authentication code from a different project, or try and refactor the authentication method in this one.It was a hard choice. We'll dump the whole block of code, but I want to pull out a few highlights, starting with the opening condition:

In this process of collecting your submissions, the single most commoncategory has been string conversions of NaN, null, and undefined. They areso common, I've become entirely bored with them. Date conversions, however,still do amuse a bit. Or will do. Or will did? Will have did? In any case,here's another installment of wibbly bits. They may not be clever, but someare a little funny.Competitive programmer Laks may have got the answer technicallyincorrect, but he did it REALLY fast. Shouldn't he have won on speed?Says Laks "It turns out you can implement flux capacitor in software."

In functional programming languages, you'll frequently see some variation of the car/cdr operations from LISP. Given a list, these functions can split it into the head (or first element) of the list, and the tail (the rest of the list). This is often used to traverse a list recursively: function f performs an operation on the head of the list, and then recursively calls f on the tail of the list.I bring this up because we're talking about C# today. C# has plenty of fun functional programming features, and you can certainly use them to write very clean, comprehensible code. Or, like Nico's co-worker, you could do something like this.

Ali was working on an app for a national government. The government provided its own mapping API for its own custom mapping services. It did not provide any documentation, and the only "sample" code was hitting "view source" on an existing map page on the government's websites.Ali writes: "I was going through their own implementations, looking for something that would help, when I stumbled upon this gem. I think it speaks for itself, no?"

There are times when performance absolutely matters. And the tech lead that Janell was working with (previously) was absolutely certain that their VB.Net project needed to be "designed for performance". Performance was so important that in the final design, they used a home-brewed JSON database (which, at its lowest level, was just a JSON file on disk), and it took 7 round-trips to their home-brewed database to read a single record.Despite all this attention on performance, the system had a memory leak! As we've covered in the past, garbage-collected languages can have leaks, but they may take a little more effort than the old-school versions. Janell fired up a debugger, looked at the memory utilization, and started trying to figure out what the problem was.The first thing Janell noticed was that there were millions of WeakReference objects. A WeakReference can hold a reference to an object without preventing garbage collection. This is the sort of thing that you might use to prevent memory leaks, ensuring that objects get released.A little more poking revealed two layers to the problem. First, every business object in the application inherited from BaseObject. Not the .NET object type that's the base class for all objects, but a custom BaseObject. Every class had to inherit from BaseObject.

The year was 2001: the year before many countries in the EU switched from using their national currency to the new euro. As part of the switch, many financial software packages had to be upgraded. Today's submitter, Salim, was hired as an IT support staffer in a medium-sized healthcare organization in the Netherlands. While Salim had a number of colleagues, they had to support a greater number of small satellite offices, and so on occasion any of them would be left to hold the main office alone. It just so happened that Salim's first solo day was the day they were testing the software upgrade, with the CFO himself executing the test.The manager of IT had prepared well. Every aspect of the test had been thought through: the production server had been cloned into a fresh desktop computer, placed in the server room, set apart from the other servers so that the CFO wouldn't accidentally touch the production server. To make it stand out, rather than a rack they'd placed the computer on one of those thin little computer desks that were in fashion at the time, a little metal contraption with a drawer for the keyboard and wheels so it could be moved. The setup got an office chair and a phone, for comfort and so that the CFO could summon help if needed. The CFO had been given step-by-step instructions from the software vendor, which he and the manager had gone over ahead of time. All the bases were covered. Hopefully.Early in the morning the day of the test, the CFO walked to the support desk and asked for access to the server room. Salim walked him to the room, unlocked the door for him, and pointed him to the computer desk. Before he left, he pointed out the phone and gave the CFO his direct extension in case anything went wrong. The CFO thanked him, and Salim left him to it.No sooner had he sat down than the call came: the CFO asking for help. Although he had a good deal of general IT knowledge, Salim hadn't personally inspected any of the instructions and didn't know much about the software. So he walked back to the server room, anxiety growing.Arriving in the server room, Salim found the CFO standing next to the computer desk. Salim sat down, pulled the keyboard out from under the monitor, and flicked on the screen. Summoning up his most professional voice, he asked, "Right, how can I help?""Ah ... thanks," came the reply. "I can manage from here."Salim writes: "To this day, I do not know if his problem was not being able to find the keyboard, or switch on the monitor." [Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.

Baby Boomer Eric D. accidentally shares the prototypical Gen Xexperience, this time via Pella windows. "I guess I can't actually buy stuffbecause I'm in the unlucky 55-64 age band." Welcome to irrelevance, Eric!

Have you ever needed to prune an order line? Y'know, prune them. This is an entirely common operation you do on orders all the time, and requires absolutely no context or explanation. There's absolutely no chance that you might need to wonder, exactly what is being pruned.Bartholomew A. was a little bit confused by the prune method in the codebase. Fortunately, reading through the code makes everything clear:

There was an era where UI designer tools output programmatic code representing that UI. So, say, if you were dragging and dropping objects in the Windows Forms designer in Visual Studio, the output would be C# code. Now, the designer would have some defaults. When you added a new button, it might identify it as button15. Of course, you wouldn't leave that name as it was, and you'd give it a meaningful name. That name would then become the property name of that field in the class generated by the designer.Well, you might give it a meaningful name. Gormo inherited some Windows Forms code, which challenges the meaning of "meaningful names".

When I was a baby programmer, I subscribed to a computer magazine. In those olden times, these magazines would come with pages of program code, usually BASIC, so that you could type this program into your computer and run it. If you were careful about typos, you could accomplish quite a bit of "programming" without actually programming. What you were doing, in practice, was just typing.One of Anthony's predecessors was quite the accomplished typist.They needed to take the built-in .NET XmlDocument class and add a one method to it. Now, C# offers a few techniques for doing this. The "traditional" object-oriented approach is to use inheritance. Now, that's not without its downsides, so C# also has the concept of "extension methods". This is a little bit of syntactic sugar, which allows you to declare static method that takes a parameter of XmlDocument, but invoke it as if it were an actual instance method. Of course, depending on what you're doing, that might not give you all the functionality you need. And outside of those techniques, there are a number of the good-ol' Gang of Four design patterns, like the Visitor pattern which could solve this problem without loads of complexity. Or even just "a plain old static method" might fit.But Anthony's predecessor didn't want to do any of those. They instead chose to use typing.

John's employer needed a small web app built, so someone in management went out and hired a contracting firm to do the work, with the understanding that once it was done, their own internal software teams would do maintenance and support.Fortunately for John's company, their standard contract included a few well-defined checkpoints, for both code quality audits and security audits. It's the last one that's relevant in this case.There are three things you should never build for your application: date handling logic, encryption algorithms, or authentication mechanisms. These are all things that sound simple on the surface, but are actually quite difficult. You will mess them up, and you'll regret it. What's remarkable here, however, is seeing how badly one can mess up authentication:

Paul M. identifies an online vendor who isn't at all afraid of the bold ask. But he demurs. "Uh, I think I'll stick with the sale price thanks."

Basecamp Management Somehow Less Self-Aware Than Andrew YangIn the lead-up to the Chappelle Show sketch ‘When Keepin’ It Real Goes Wrong’, Dave Chappelle gives the following pretty great advice:“It’s good to be real sometimes. It’s good to be phony sometimes. Yes, I said it. Phony! You think I’m this nice in real life? F$ck that son!”We tend to stay real with the people when we benefit from telling the truth to them and hearing the truth from them, while we stay phony when we feel that we benefit from emotional investment.Take a second to do an exercise splitting society into those that you should be “real” to/with and those that you should stay “phony” to/with. Here’s my take: Be Real (to and with) Stay Phony (to and with) Parents, Spouses, Young Children*, Teenagers Extended Family Healthcare Workers Celebrities + Self-Promoters Political candidates (someone desperately needs to get real with Andrew Yang) Elected Officials + Business Leaders Co-workers Bosses + Management (In Venkatesh Rao’s amazing six-part Gervais Principle breakdown of ‘The Office’ and management, he would argue that there lies a third column of people who think they are Real but actually Phony. It’s seriously worth your time to read the full piece. But for simplicity sake, I will keep these two columns.)So where am I going with all this? Let’s talk about Basecamp.First, the definition of a ‘basecamp’ is the following: a main encampment providing supplies, shelter, and communications for persons engaged in wide-ranging activities, as exploring, reconnaissance, hunting, or mountain climbing. What does a company who builds project management and communications tools, who changed their name from 37 Signals in 2014, have to do with adventure sports? Unclear.Second, Basecamp had ~60 employees as of two weeks ago, but has written 5 books on management (!!). Basecamp must have the highest books written per employee rate of any company in history.Oh yeah and third, management decided to get real with their employees by setting up a company-wide meeting to discuss banning political discussion in the office and ⅓ of their employees immediately accepted buyouts afterwards.There are a lot of extremely smart pieces of the lead-up and aftermath of the debacle, so I recommend reading Casey Newton’s full piece at Platformer, Charlie Warzel’s piece at Galaxy Brain, and Vice’s piece.But here’s simple take:

If you go by the popular press articles on the tech field, anyone who's anyone has migrated into the "machine learning" space. That's where all the "smart" programmers go.Of course, ML is really just statistics and automated model fitting. It's a powerful tool, and it does require some highly specialized skills- skills that might involve programming, but maybe don't quite overlap with programming.Noreen inherited some code from a highly-paid contractor who specializes in doing machine learning. The HPC put together an ML system capable of generating all sorts of useful output, output which the users at Noreen's company wanted compiled into nice PDFs. The HPC, being a very busy ML consultant who billed $300/hr didn't want to build this, so they subcontracted out to different HPC, who also was in the ML space, but billed at $200/hr.The result is about 500 lines of Python script, in one large Python file. There's no real organization, no clear entry point, and all sorts of… interesting choices. Let's start with the very first method:

When RJ was trawling through some SQL Server stored procedure code, they spotted this line:

For those looking to get into software development, there's never been more access to tutorials, guides, training programs, and communities of developers ready to foster those trying to get started.Unfortunately, you've got folks that think because they've written a few websites, they're ready to teach others, and write up their own tutorials without having the programming background or the educational background to effectively communicate best practices to the public.A few years back, Rob Speed was poking at a course calling itself "JavaScript Best Practices". One slide, quite correctly, warned: "If numerical data comes from a form, it may appear as a string. Parse the data before performing validation." And, by way of example, it supplied this code, for parsing postal codes:

With all the investments that have recently been made instatistical/brute-force methods for simulating machineintelligence, it seems that we may at least at last haveachievedthe ability to err like a human.Patient Paul O. demonstrates that bots don't work well before they've hadtheir coffee any more than humans do. "I spent 55 minutes on this chat, most of it with a human in the end, although they weren't a lot brighter than the bot."

Sometimes bad code arises from incompetence, whether individual, or more usually institutional. Sometimes it's overly tight deadlines, misguided architecture. And sometimes… it's just the easiest way.Naomi writes in to confess to some bad code.

Unit testing in C offers its own special challenges. Unit testing an application heavily dependent upon threads, written in C, offers even more.Brian inherited an application where the main loop of the actual application looked something like:

Shipping meaningful data from one company's IT systems to another company's IT systems is one of those problems that's been solved a billion times, with entirely new failure modes each time. EDI alone has a dozen subspecifications and allows data transfer via everything ranging from FTP to email.When XML made its valiant attempt to take over the world, XML schemas, SOAP and their associated related specifications were going to solve all these problems. If you needed to communicate how to interact with a service, you could publish a WSDL file. Anyone who needed to talk to your service could scrape the WSDL and automatically "learn" how to send properly formatted messages. The WSDL is, in practice, a contract offered by a web service.But the WSDL is just one mechanism to provide a specification for software. Which brings us to Patrick.Patrick needed to be able to transmit financial transactions from one of their internal systems to a vendor in France. Both parties discussed the requirements, what specific fields needed to be sent, how, what they actually meant, and hammered out a specification document that confirmed their understanding. It would be a SOAP-based web service, and the French team would be implementing it on their end."Great," Patrick said in one of their meetings. "Once you've got the interface defined according to our specification, you should send us the WSDL file."The next day, they received a WSDL file. It was a "hello world" file, autogenerated for a stub service with one method- helloWorld."That isn't what we're expecting," Patrick emailed back. "Could you please send us a WSDL which implements the spec?"The next day, Patrick got a fresh WSDL. This one looked vaguely like the specification, in that some of the methods and fields were named correctly, but half of them were missing."We don't need to rush this," Patrick said, "so please review the specification and ensure that the WSDL complies with the specification we agreed to."Two days later, Patrick got a "hello world" WSDL again, followed by a WSDL for a completely unrelated web service.Over the next few weeks, the vendor team produced a steady stream of WSDL files. Each was incorrect, sometimes wildly off target, sometimes simply missing a few fields. One Thursday, seemingly by accident, the vendor team sent a correct WSDL, and immediately followed up with another one missing half the key fields.Eventually, they send a WSDL that more-or-less matched the spec, and stopped trying to "fix" it. Development on both sides progressed, at the glacial pace that any enterprise integration project goes. Development happened less often than meetings, and milestones slid by at an absolutely glacial pace.But even glaciers move. So the day came for the first end-to-end test. Patrick's team sent a SOAP request containing a valid transaction.They got no response back.Patrick got his opposite number in France, Jean, on the phone, and explained what he was seeing."No," Jean said. "I can see that you are sending requests, but your requests are empty.""We are not sending empty requests," Patrick said."Apologies, but yes, you are."Patrick's team set up logging and tracked every outgoing request, and its payload. They manually validated it against the WSDL. They programatically validated it against the WSDL.Patrick went back to Jean with his evidence."No, the problem must be on your side.""Well, I've provided my logs," Patrick said. "What logging are you getting on your side? Maybe something in the middle is messing things up?""One moment," Jean said. Patrick listened to him typing for a bit, and then some puzzled mumbling. Then a long stretch of silence."Uh, Jean?"The silence stretched longer."You still there?""Oui," Jean said, distantly. "I… ah, I cannot find the logs. Well, I can find logs, just not, the logs for this service. It appears it is not installed on our test server.""You… didn't install it? The thing we're explicitly testing? It's not installed.""Yes. I do not have permissions to release that code. I'll have to set up a meeting."They aborted the test that day, and for many days thereafter. When they did finally test, the vendor team deployed an old version, with a "hello world" WSDL. Eventually, the customer that requested this integration got frustrated with waiting, and switched to a different set of vendors that could actually communicate with each other. To this day, that test server is still probably running with a "hello world" WSDL. [Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!

Much of the stories and code we see here are objectively bad. Many of them are bad when placed into the proper context. Sometimes we're just opinionated. And sometimes, there's just something weird that treads the line between being an abuse of code, and almost being smart. Almost.Nic was debugging some Curses-based code, and found this "solution" to handling arrow key inputs:

We are all hopeful that there might be some cause for tentative optimism regarding the eventual end of coronavirus pandemic. But horror fan Adam B. has dug up a new side effect that may upend everything.

Many years ago, I worked for a company that mandated that information like user credentials should never be stored "as plain text". It had to be "encoded". One of the internally-developed HR applications interpreted this as "base64 is a kind of encoding", and stored usernames and passwords in base64 encoding.Steven recently encountered a… similar situation. Specifically, his company upgraded their ERP system, and reports that used to output taxpayer ID numbers now outputs ~201~201~210~203~… or similar values. He checked the data dictionary for the application, and saw that the taxpayer_id field stored "encrypted" values. Clearly, this data isn't really encrypted.Steven didn't have access to the front-end code that "decrypted" this data. The reports were written in SSRS, which allows Visual Basic to script extensions. So, with an understanding of what taxpayer IDs should look like, Steven was able to "fix" the reports by adding this function:

Pierre inherited a PHP application. The code is pretty standard stuff, for a long-living PHP application which has been touched by many developers with constantly shifting requirements. Which is to say, it's a bit of a mess.But there's one interesting quirk that shows up in the codebase. At some point, someone working on the project added a kinda stock way they chose to handle exceptions. Future developers saw that, didn't understand it, and copied it to just follow what appeared to be the "standard".And that's why so many catch blocks look like this:

At a certain point, it becomes difficult to write a unit test without also being able to provide mocked implementations of some of the code. But mocking well is its own art- it's easy to fall into the trap of writing overly complex mocks, or mocking the wrong piece of functionality, and ending up in situations where your tests end up spending more time testing their mocks than your actual code.Was Rhonda's predecessor thinking of any of those things when writing code? Were they aware of the challenges of writing useful mocks, of managing dependency injection? Or was this Java solution the best they could come up with:

Josh's company hired a contracting firm to develop an application. This project was initially specced for just a few months of effort, but requirements changed, scope changed, members of the development team changed jobs, new ones needed to be on-boarded. It stretched on for years.Even through all those changes, though, each new developer on the project followed the same coding standards and architectural principles as the original developers. Unfortunately, those standards were "meh, whatever, it compiled, right?"So, no, there weren't any tests. No, the code was not particularly readable or maintainable. No, there definitely weren't any comments, at least if you ignore the lines of code that were commented out in big blocks because someone didn't trust source control.But once the project was finished, the code was given back to Josh's team. "There you are," management said. "You support this now."Josh and the rest of his team had objections to this. Nothing about the code met their own internal standards for quality, and certainly it wasn't up to the standards specified in the contract."Well, yes," management replied, "but we've exhausted the budget.""Right, but they didn't deliver what the contract was for," the IT team replied."Well, yes, but it's a little late to bring that up.""That's literally your job. We'd fire a developer who handed us this code."Eventually, management caved on documentation. Things like "code quality" and "robust testing" weren't clearly specified in the contract, and there was too much wiggle room to say, "We robustly tested it, you didn't say automated tests." But documentation was listed in the deliverables, and was quite clearly absent. So management pushed back: "We need documentation." The contractor pushed back in turn: "We need money."Eventually, Josh's company had to spend more money to get the documentation added to the final product. It was not a trivial sum, as it was a large piece of software, and would take a large number of billable hours to fully document.This was the result:

Waiting for his wave to collapse, surfer Mike I.harmonizes "Nice try Power BI, but you're not doing quantum computing quite right." Or, does he?

When you look at bad code, there's a part of your body that reacts to it. You can just feel it, in your spleen. This is code you don't want to maintain. This is code you don't want to see in your code base.Sometimes, you get that reaction to code, and then you think about the code, and say: "Well, it's not that bad," but your spleen still throbs, because you know if you had to maintain this code, it'd be constant, low-level pain. Maybe you ignore your spleen, because hey, a quick glance, it doesn't seem that bad.But your spleen knows. A line that seems bad, but mostly harmless, can suddenly unfurl into something far, far nastier.This example, from Rikki, demonstrates:

Let’s quickly recap the past three news roundups:

Universally Unique Identifiers are a very practical solution to unique IDs. With 10^30 possible values, the odds of having a collision are, well, astronomical. They're fast enough to generate, random enough to be unique, and there are so many of them that- well, they may not be universally unique through all time, but they're certainly unique enough.Right?Krysk's predecessor isn't so confident.

Imagine you were browsing a C++ codebase and found a signature in a header file like this:

After reading through so many of your submissions these last few weeks,I'm beginning to notice certain patterns emerging. One of these patterns isthat despite the fact that dates are literally as old as time, people seem pathologically prone to bungling them. Surely our readers are already familiar with the notable "Falsehoods Programmers Believe" series of blog posts, but if you happen somehow to have been living under an Internet rock (or a cabbage leaf) for the last few decades, you might start your time travails at Infinite Undo.The examples here are not the most egregious ever (there are better coming later or sooner) but they are today's:Famished Dug S. peckishly pronounces "It's about time!"

Steven was working on a temp contract for a government contractor, developing extensions to an ERP system. That ERP system was developed by whatever warm bodies happened to be handy, which meant the last "tech lead" was a junior developer who had no supervision, and before that it was a temp who was only budgeted to spend 2 hours a week on that project.This meant that it was a great deal of spaghetti code, mashed together with a lot of special-case logic, and attempts to have some sort of organization even if that organization made no sense. Which is why, for example, all of the global constants for the application were required to be in a class Constants.Of course, when you put a big pile of otherwise unrelated things in one place, you get some surprising results. Like this: