I'll give an example. At my previous company there was a program where you basically select a start date, select an end date, select the system and press a button and it reaches out to a database and pulls all the data following that matches those parameters. The horrors of this were 1. The queries were hard coded.

They were stored in a configuration file, in xml format.
The queries were not 1 entry. It was 4, a start, the part between start date and end date, the part between end date and system and then the end part. All of these were then concatenated in the program intermixed with variables.
This was then sent to the server as pure sql, no orm.
Here's my favorite part. You obviously don't want anyone modifying the configuration file so they encrypted it. Now I know what you're thinking at some point you probably will need to modify or add to the configuration so you store an unencrypted version in a secure location. Nope! The program had the ability to encrypt and decrypt but there were no visible buttons to access those functions. The program was written in winforms. You had to open the program in visual studio, manually expand the size of the window(locked size in regular use) and that shows the buttons. Now run the program in debug. Press the decrypt button. DO NOT EXIT THE PROGRAM! Edit the file in a text editor. Save file. Press the encrypt button. Copy the encrypted file to any other location on your computer. Close the program. Manually email the encrypted file to anybody using the file.

you are viewing a single comment's thread
view the rest of the comments

[–] jubilationtcornpone@sh.itjust.works 15 points 2 days ago* (last edited 2 days ago) (1 children)

First One:

Big ASP.Net Core Web API that passed through several different contract developer teams before being finally brought in house.

The first team created this janky repository pattern on top of Entity Framework Core. Why? I have no idea. My guess is that they just didn't know how to use it even though it's a reasonably well documented ORM.

The next team abandoned EFCore entirely, switched to Dapper, left the old stuff in place, and managed to cram 80% of the new business logic into stored procedures. There were things being done in sprocs that had absolutely no business being done there, much less being offloaded to the database.

By the time it got to me, the data layer was a nightmarish disaster of unecesary repo classes, duplicates entities, and untestable SQL procedures, some of which were hundreds of lines long.

"Why are all our queries running so slow?"

We'll see guys, it's like this. When your shoving a bunch of telemetry into a stored procedure to run calculations on it, and none of that data is even stored in this database, it's going to consume resources on the database server, thereby slowing down all the other queries running on it.

Second One:

Web app that generates PDF reports. Problem was it generated them on-the-fly, every time the PDF was requested instead of generating it once and storing it in blob storage and it was sllloowwwww. 30 seconds to generate a 5 page document. There were a list of poor decisions that led to that, but I digress.

Product owner wants the PDF's to be publicly available to users can share links to them. One of the other teams implements the feature and it's slated for release. One day, my curiosity gets the best of me and I wonder, "what happens if I send a bunch of document requests at once?" I made it to 20 before the application ground to a halt.

I send a quick write up to the scrum Master who schedules a meeting to go over my findings. All the managers keep trying to blow it off like it's not a big deal cause "who would do something like that?" Meanwhile, I'm trying to explain to them that it's not even malicious actors that we have to be concerned about. Literally 20 users can't request reports at the same time without crashing the app. That's a big problem.

They never did fix it properly. Ended up killing the product off which was fine because it was a pile of garbage.

[–] vrek@programming.dev 5 points 2 days ago (2 children)

I think this is the problem with legacy code. It's not that it's old but that 35 people each with their own coding standards and practices.

[–] jubilationtcornpone@sh.itjust.works 6 points 2 days ago (1 children)

One of my old bosses used to say, "the choice is often not between right and wrong, but good, better, and best."

I agree with that sentiment for the most part. Different styles is fine. But sometimes you run into someone who is trying to use a socket wrench to drive nails and all you can do is just kind of watch in amazement and wonder how they arrived at the conclusion that this was the way to go.

[–] olafurp@lemmy.world 4 points 1 day ago

I would go for "garbage, bad and ok" where bad is acceptable. Most styles are ok, a lot of anti-patterns are bad but still get the job done but sometimes people write pure garbage. I'm very happy that at my job we just have a lot of bad code that's workable but this one contractor wrote an absolute piece of shit. His code was a convoluted side-effect mess that was "reactive" and at around 3-5x more verbose than the "naive" solution. He made so many decisions that increased complexity and overhead that it become a rigid buggy mess.

Sometimes people just need to stick to the basics by using a database layer and a service layer on the backend and a API layer and component code on the front.

[–] chunkystyles@sopuli.xyz 1 points 1 day ago

And all it takes is for one of those folks to be motivated and stupid to really muck things up.