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
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.
"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*
"And you never considered replacing it?"
"Oh, we *considered* it a bunch of times. We didn't do it, because without it, about 80% of the data from before 2016 becomes unreadable, and we only understand three of the reasons that happens."
"...how many reasons are there?"
"At least four"
Hey, did you, or one of your colleagues, give a presentation at linux.conf.au about the Dreamwidth codebase several years back? I'm trying to jog my memory or find a video.
"Okay, so this database field is JSON encoded, because it went from holding the answers to three questions, to holding the answers to up to 55 questions, some of which became optional or irrelevant based on answers to previous questions, for a data gathering process that no one used after 6 months."
“idk man we’re figuring this out as we go” works pretty well for small services because users feel like part of the community around it and are very willing to extend grace
when you get Very Big they start expecting that you not do that unfortunately
It genuinely depends -- I've seen it work at much much larger scale than we run. It all depends on how much your users perceive it as Bullshit. Users are incredibly sensitive to Bullshit and once any of your communication is Bullshit, all of it will be perceived to be
But being honest all the time works for a surprisingly long time. It doesn't work for any of the large platforms because they've established themselves as willing to post Bullshit, not because of anything inherent to the size.
I think the process of becoming a large platform makes them much more prone to posting bullshit
you get more users with more varied complaints so communication tends to get more corporatized and professional, which has a high correlation with bullshit
People have *exquisite* Bullshit detectors. Don't feed them some line about "the safety of our application" blah blah blah, just straight up say "yeah, if we don't do this Apple will pull our app from the App Store", etc
I think who it comes from makes a big difference.
Paul and the other devs are part of the community and have been pretty open with challenges and lessons learned.
"we're just trying stuff and working it out" comes off very differently there than when it's run through corporate comms
People have *exquisite* Bullshit detectors. Don't feed them some line about "the safety of our application" blah blah blah, just straight up say "yeah, if we don't do this Apple will pull our app from the App Store", etc
Fuck, man, I could not agree more and I don't know why this is a hard question for people. Should the org sound like an LLM-generated PR manual to its human constituencies? No of fucking course not
Even as I scratch my head on certain things (*ahem* starter pack safety), I don't envy you the PR duties that seem to have tagged along with your visibility.
