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 filters. Our hot list 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()

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.

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.

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.

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

ORMs are overrated.

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.

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.

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 💪

It was a Java project and every class was in a separate Maven module.

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.