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

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 PFD 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.

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.

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.

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.

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.

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…

I’ve seen a many-to-many relationship written as a column of CSV ids.

Also same ppl used “ID” instead of “id” (sometimes Id even) which made ORMs cry hard

The encryption thing is definitely weird/crazy and storing the SQL in XML is kinda janky, but sending SQL to a DB server is literally how all SQL implementations work (well, except for sqlite, heh).

ORMs are straight trash and shouldn’t be used. Developers should write SQL or something equivalent and learn how to properly use databases. eDSLs in a programming language are fine as long as you still have complete control over the queries and all queries are expressable. ORMs are how you get shit performance and developers who don’t have the first clue how databases work (because of leaky/bad abstractions trying to pretend like databases don’t require a fundamentally different way of thinking from application programming).

Sounds like a motel horror story.

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.

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.

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

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.