Performance-based limiting (and figuring out what the correct limits should be to not impact legitimate use but also serve as a guardrail against Shit Breaking) is a very hard problem and it's really common to launch with much lower limits than you think you can handle Just In Case
Generally when you notice limits like this when something first launches, it's "we're worried we may not have calculated the performance impact well enough so we're being conservative, let's set it low and see how many people run into it".
Also (don't tell anyone) a lot of times devs are just completely guessing at limits. "What should we set this to? Eh, seven is a good number, I like seven"
Our users really like it when we tell them "we totally made that number up and it will probably change in the future!" Admitting we are not all knowing also makes them more forgiving of fuckups, heh
My favorite version of this is where someone building a system creates a workflow, then hands the system off to another, bigger team
And that team treats that workflow like it's gospel because they didn't build it
Meanwhile it's built that way so I could avoid worrying about working weekends
My codebase is 25 years old and my cofounder and I were around for like 23 of them (we forked from another project we'd both worked on) so occasionally people come to us and ask "why does it--" and they know that when the answer starts with "okay, so--" they should prepare for horrors
There was one horrible hack, I forget exactly what, where the Modern Technologies Frontend Guy went "this makes NO SENSE, what went ON here" and after we explained he was both horrified and also conceded there was literally no better solution possible so he was going to have to do the same thing
Did I mention we're 25 year old legacy Perl running on a templating language (that thankfully we're moving off of, though not as fast as we'd like) that was only ever used in one other place and it was the original founder's prior project, heh
also I went looking through our Discord for some other fun stories and found the platonic example of "how people universally react when they start digging into something"
I recently updated something very much like this. My favorite part was the first form validation failure we encountered: the jQuery selector it used for the relevant input was based on its position in the layout table, using five chained child() functions.
Eh, I've seen (and written) much worse. Mostly the multiple pages of .= and use of `my $foo_bar = sub { }` (and slightly nonorthogonally named at that) make my brow furrow a bit, but it also has the air of "there were reasons to do it like that at the time", and is still usable 16-yo code
in our defense, we used the LiveJournal source because it was battle tested and performance hardened and it has held up *amazingly* in the 15 years since we forked it, but oh god so much technical debt
Cold Fusion?!
*starts a 2 pack a day smoking habit just so he can take a sufficiently deep and ennui-filled drag on a cigarette*
There’s a name I haven’t heard in… a very long time.
I'm still oddly proud of my (ab)use of the style engine when I implemented an entirely different calendar system from the multi-million-word Journal Entries series/metaverse (warning, it's erotica!) for my journal at one point.
But that might be indicative of how overly capable the templating was.
God, the degree of control we give people is amazing. One user worked out a layout that looked exactly like the Windows 10 desktop. Another person implemented Towers of Hanoi in their layout. We absolutely give people too much control, heh.
Once worked on an ASP site that crashed on the first user visit after new deployments but ran fine once restarted after that. Only once, only the first time and only if the user used a specific IE version.
Nope. Tried everything we could think of and started spoofing the user agent but nada. I suspect it's just something about IIS responding to IE. Was easier in the end to just make hitting the site and restarting the server a part of the deployment process.
"Okay so in August 2014 my computer crashed and it was the end of a sprint and we had to close out so I had to work on a Mac from 1996 for two days while Best Buy shipped me a replacement."
"And that's why this the decisioning here is done with an embedded hypercard stack"
"Correct, yes"
We occasionally still get disasters stemming from the fact that LiveJournal had broad international adoption among languages with non-ISO8859 alphabets before Perl or MySQL handled UTF-8 properly *at all*
We hacked UTF-8 support together to a degree of Good Enough For Now, then Perl and MySQL caught up but Perl's implementation was terrible for like another two years so we forced everything to keep going through our old solution, and then everything caught up and surprise! Now it's a problem!
It is now 2024 and we *still* have that bite us in the ass every few years with old data. Absolutely the correct technical decision at the time, wouldn't change a goddamn thing, have still had to troubleshoot more WTF-8 disasters than I ever wanted (one is too many)
rah, I don't know if you recall that one I mentioned I worked on with a century indicator that wasn't 0=1900;1=2000, but had weird logic of 0=1900 if the year is greater than 38 (or close to).
But it took me until last week (literally) to realize they probably did this because of the Epoch problem.
