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.

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

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

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…

Joined a new team and one of my first tasks was a refactor on a shared code file (Java) that was littered with data validations like if ("".equals(id) || id == null) { throw new IllegalArgumentException() }

The dev who wrote it clearly was trying to make sure the string values were populated but they apparently A) didn’t think to just put the null check first so they didnt have to write their string comparison so terribly or else didnt understand short circuiting and B) didn’t know any other null-safe way to check for an empty string, like, say StringUtils.isEmpty()

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.

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.

This was then sent to the server as pure sql, no orm.

ORMs are overrated.

There are a couple that come to mind.

Definitely the worst, a C# .net mvc application with multiple controllers that were 10s of thousands of lines long. I ran sonarqube on this at one point and it reported over 70% code duplication.

This code base actively ignored features in the framework that would have made things easier and instead opted to do things in ways that were both worse, and harder to do. For example, all SQL queries were done using antiquated methods that, as an added benefit, also made them all injectable.

Reading the code itself was like looking at old school PHP, but c#. I know that statement probably doesn’t make sense, but neither did the code.

Lastly, there was no auth on any of the endpoints. None. There was a login, but you could supply whatever data you wanted on any call and the system would just accept it.

At the time I was running an internal penetration test team and this app was from a recent acquisition. After two weeks I had to tell my team to stop testing so we could just write up what we had already and schedule another test a couple months down the line.

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.

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.

My university uses ORACLE. To make a payment from a research account, you need to manually input a 15 character chart string. Every time.

Whatever im working on 💪