Programmer Humor

A program that HR had built so that all employees could they their payment receipts online

The username was the companies' email address, the password was a government personal id code that you can lookup online, a don't change, and you can't update the password to something else.

So I told the director of HR this was a bad idea. She told me I was overreacting until I showed her her own receipt, then she finally understood that this is a really fucking bad idea.

Okay, so now she out me in charge of debugging that program.

So I setup a meeting with the director of the company they hired, he came by with the developer: a 21 yo girl who I think hadn't finished college yet. Great start! Apparently it was her idea to do the authentication like that so that explains a few things.

So we dive in to the code.

First of all, the "passwords" were stored in blank, no hashing, no encryption, nothing. That wasn't the worst.

For the authentication she made a single query to check if the user email existed. Of that was true, then step two was a second query to see if the password existed. If that were true, the email had been authenticated.

So let's say, hypothetically, that they had actual passwords that people could change... I could still login with the email from anyone, and then use MY OWN password to authenticate.

This just blew my mind so hard that I don't think I ever fully recovered, I still need treatment. The stupidity hurts

There was something like

# sleep for about a second on modern processors
math.factorial(10000)

After it was found we left it in the code but commented out along with a sleep(1) for posterity.

Private key for a third-party API hard-coded into the front-end web app

Lots. But one that springs to mind is a custom CMS where a new dev decided to print out the sql generated for a particular content type on paper. He took it to the CTO without comment.

What was wrong?

It was 12 pages.

A bit late to the party on this one, but Facepunch just opensourced a bunch of their code, I nominate that.

This one is funny because it 100% still exists somewhere, but I haven't had the chance to verify it again.

Okay so basically its a data recorder box (ex: brainbox) that connects to a bunch of industrial sensors and sends the data over the network with your preferred method.

Builtin firmware gives you an HTTP webui to login and configure the device, with a user # and password.

I think the user itself had a builtin default admin which was #0, which everyone uses since there wasn't really much use for other users.

Anyway, I was looking at the small JS code for the webui and noticed it had an MD5 hashing code that was very detailed with comments. It carefully laid out each operation, and explained each step to generate a hash, and then even why hashes should be used for passwords.

Here's the kicker: It was all client side JS, so the login page would take your password, hash it, and then send the hash over plaintext HTTP POST to the server, where it would be authenticated.

Meaning you could just mitm the connection to grab the hash, and then login with the hash.

I sat there for like 10 minutes looking at the request over and over again. Like someone was smart enough to think "hey let's use password hashing to keep this secure" and then proceeded to use it in the compleltly wrong way. And not even part of like a challenge/handshake where the server gives you a token to hash with. Just straight up MD5(password).

It was so funny because there were like a hundred of these on a network, so getting a valid hash was laughably easy.

I never got to check if this was fixed in a newer firmware version.

The architect sending a pointer over an API, in hexadecimal string format. char *c = "71E4F33B" just cast it on the right structure bro.

Just to add, we only did C/C++, on windows mfc, in a monolithic software.

I spent quite some time assuring myself that I was not the insane person before bringing it up with him.

The C++ code went something like this:

1. Conver pointer to int
2. Serialize the int over IPC to self using Linux Message Queues
3. Delete/free the pointer
4. Read the int from the queue
5. Convert to pointer
6. "Use" the pointer

XML-DOM page templates stored in a database, line by line.

So rendering a page started with:

select * from pages

where page_id = 'index'

order by line_number asc;

Each line of XML from each record was appended into a single string. This string was then XSLT transformed to HTML, for every page load.

Ok so this one is someone trying to move to "the cloud."

They had a database they used. It was on a server in the office. We were tasked to clone the db server to a hosted VM. Due to order of creation this got put on a new host without anything yet on it.

They needed a site to site VPN to keep privacy, that was all fine. However after the clone and during testing, their guy there said that this one part was really slow. We take a look and everything is good with performance of the server and of the VPN. I have to pop on to take a look.

It was in an office app and written in VB. (I forgot which one.) It was indeed slower on the hosted server. So I took a look at the function (he got it up for me) and I could instantly tell the issue.

This part was a lookup page that searched for you input. The function retrieved the entire table, then filtered the results in the client. I explained that transferring the whole table over the internet would be slower than on the local lan.

This guy said he originally wrote this, but "forgot VB."

In the end they decided not to update the app or keep the server in the office, but instead they rented some VDIs in the same data centre as the db.

So this is not as bad as some of the other stories I've seen, but I'll bite.

It was an old .NET Framework MVC app. Some internal product management system or something. There was a need to do a PDF export in one of the use cases, so someone implemented it. It wasn't a good implementation: one big controller, mixing UI and business logic, etc. However, it basically came down to a single private method in a specific controller for a page.

Now time passes and lo and behold, we need a PDF export in another page for a different use case. "No problem," - same dev, probably - "I already solved this problem. I'll just reuse the PDF generation logic."
Now, any sane person would probably try to refactor the code responsible for PDF stuff into a separate service (class) and reuse it. A less sane, but somewhat, acceptable approach would have been to just copy paste the thing into another controller and call it a day.

Ha! No no no no no no… Copy pasting is bad, code should be reused…

The end solution: REFLECTION. So the dev decided that the easiest way to make it work was to: 1) use reflection to inject one controller into another; 2) then use reflection again to get access and call that private method for PDF rendering into a stream.

Fortunately I didn't have to fix that fragile mess. But I did my fair share of DevExpress corpse hacking and horrible angular "server side rendering" workarounds.

For anyone who knows and understands Android development, process death, and saved state...

The previous dev had no understanding of any of it, and had null checks with returns or bypassing important logic littered all over the app, everywhere.

I could only assume he didn't understand how all these things were randomly null or why it was crashing all the time so he thought oh, i'll just put a check in.

Well, you minimize that app for a little bit, reopen it, and every screen was fucked visually and unusable, or would outright crash. It was everywhere. This was before Google introduced things like view models which helped but even then for awhile weren't a full solution to the problem.

It was many many months of just resolving these problems and rewriting it the correct way to not have these problems.

I don't have any specific examples, but the standard of code is really bad in science. I don't mean this in an overly judgemental way — I am not surprised that scientists who have minimal code specific education end up with the kind of "eh, close enough" stuff that you see in personal projects. It is unfortunate how it leads to code being even less intelligible on average, which makes collaboration harder, even if the code is released open source.

I see a lot of teams basically reinventing the wheel. For example, 3D protein structures in the Protein Database (pdb) don't have hydrogens on them. This is partly because that'll depend a heckton on the pH of the environment that the protein is. Aspartic acid, for example, is an amino acid where its variable side chain (different for each amino acid) is CH2COOH in acidic conditions, but CH2COO- in basic conditions. Because it's so relative to both the protein and the protein's environment, you tend to get research groups just bashing together some simple code to add hydrogens back on depending on what they're studying. This can lead to silly mistakes and shabby code in general though.

I can't be too mad about it though. After all, wanting to learn how to be better at this stuff and to understand what was best practice caused me to go out and learn this stuff properly (or attempt to). Amongst programmers, I'm still more biochemist than programmer, but amongst my fellow scientists, I'm more programmer than biochemist. It's a weird, liminal existence, but I sort of dig it.

Oh boy, this one was a doozy...

Was working at a very big company named after a rainforest on smart home products with integrations for a certain home assistant...

New feature was being built that integrates the aforementioned home assistant with customer's printers so they can ask the assistant to print stuff for them.

The initial design lands from our partner team with a Java backend service fairly nicely integrated with some CUPS libraries for generating the final document to be sent to the customer's printer. All good.

They are about to launch when... uh oh... the legal team notices an AGPL licensed package in one of the CUPS library's dependencies that was absolutely required for the document format needed by the project and the launch is cancelled.

So the team goes off in a panic looking for alternatives to this library and can't find any replacements. After a month or two they come back with their solution...

Instead of converting the document directly in the backend service with the linked CUPS library (as AGPL is a "forbidden license" at this company) the backend uploads the initial document to an S3 bucket, then builds a CUPS document conversion bash shell script using some random Java library, the shell script is then sent (raw) to a random blank AWS host that comes prepackaged with CUPS binaries installed (these hosts were not automated with CI/CD / auto updates as was usually mandated by company practice because updating them might remove the CUPS binaries, so they required a ton of manual maintenance over the service's lifetime...), the bash shell script is then executed on that "clean" host, downloading the document from S3, converting it via the CUPS command line binary, then reuploading it to another S3 bucket where the Java backend picks it up and continues the process of working the document through the whole backend pipeline of various services until it got to the customer's printer.

This seemed to satisfy the legal team at the very least, and I have no doubt is probably still in production today...

The kicker though? After all those months of dev work from a whole team (likely all on 6 figure salaries), and all the time spent by various engineers including myself on maintenance and upkeep on that solution after it was transferred to us?

An alternative, completely unrestricted corporate license was available for the package in question for about $100 per year so long as you negotiated it with the maintainers.

But that was a completely unacceptable and avoidable cost according to upper management...

Whatever is happening in Monster Hunter Wilds.

There was a website where users could request something or other, like a PDF report. Users had a limited number of tokens per month.

The client would make a call to the backend and say how many tokens it was spending. The backend would then update their total, make the PDF, and send it.

Except this is stupid. First of all, if you told it you were spending -1 tokens, it would happily accept this and give you a free token along with your report.

Second of all, why is the client sending that at all? The client should just ask and the backend should figure out if they have enough credit or not.

I think the worst software-gore I remember seeing was a web app that dumped all the data to the browser as a huge XML file and then had JavaScript translate the contents of the xml into views. That probably wouldn’t even sound that far off the reservation now if it was JSON, thanks to the sleepless efforts of the JavaScript industrial complex, but back then you’d just render pages and return them.

Weather forecasting software that maintains a linked list. When it eventually freed the memory used by the list, it would walk to the end of the list and free the last item. Then it would go back to the beginning of the list and do it again - rinse and repeat. Wonder why it was having performance issues 🙄

We had some super old code in our company monorepo that was written by someone who became the CTO, there was a comment forbidding people from writing private methods in the code base because "we aren't babies". It explained so much about the awful code and why everything was crazy.

First of all, lack of ORM isn’t bad. It’s not a good or bad thing to use them out not use them. What’s bad is not sanitizing your query inputs and you don’t need an ORM to do that.

I think the worst thing I’ve seen is previous devs not realize there’s a cost to opening a DB connection. Especially back when DBs were on spinning rust. So the report page that ran one query to get the all the items to report on, then for each row ran another individual query to get that row’s details was probably one of the slowest reports I’ve ever seen. Every DB round trip was at minimum 0.1 seconds just to open the connection, run the query, send back the data, then close the connection. So 10 rows per second could be returned. Thousands of rows per page has people waiting several minutes, and tying up our app server. A quick refactor to run 2 queries instead of hundreds to thousands and I was a hero for 10 min till everyone forgot how bad it was before I fixed it.

I got forcefully moved onto another team at work. They use Observables to replace signals, change detection, local storage, and even function calls. Every single component is a tangled mess of Observables and rxjs. Our hotlist has over 300 bugs, and the app is like 6 months old.

I've been looking for a new team

Here is my story:

There were console outputs after nearly every line. I asked about them: "Oh, I couldn't get the debugger to work, so I print everything to the console"

This was everywhere. The whole program was like this. On a standard Linux machine. It wasn't even remote debugging or something. Just a local C++ program.

The filenames where written in 8+3. Again, on a modern Linux machine. His answer? "You never know where we'll port this software to"

Onto computers that were outdated decades ago? To embedded systems? Of course he had no answer for this except "just in case..."

I could tell you more, that software was the stuff for nightmares.

Back in the day, a C program to handle estimating procurement costs for complex government contracts. We had to figure out the code and write in in a different language. It was just one giant loop, no functions, with variables named V1, V2, V3, etc. Hundreds and hundreds of them. I still shudder at the horror of it all.

At a small company I used to work for we agreed to take over the management system for someone trading physical resources. The guy that originally wrote it was self taught. We did a hand over with him where he took us through the code base. It was written in dotnet but it was a huge mess, he had blended multiple different dotnet paradigms, there was mixed business and UI code all over the place, large chunks of html were stored in the db, db code was just scattered through the application. We took it over briefly but it was a nightmare to work on and we found a SQL injection vulnerability. So as kindly as possible we told the client that his software was a piece of shit and the dev he hired had no idea what he was doing.