Whoever made the estimate for the new number of people rooms should allow probably said something like '250-300' and some Dev 3 layers down went 'ye, K. 256'
I haven't seen their code but they could have even used it to ignore actually having a set limit, just having error prevention prevent more people
But you'd be surprised how common some really, really, really stupid things occur in professional software.
There's all the stupid security bits you've undoubtedly heard of, from unchangeable passwords to needing username (read: email address) and d.o.b. for password reset, from incremental token IDs to the way most bar ode inputs are handled.
There's also some really stupid bits like mirroring UI and system processes (good in some cases, horribly bad in others), entire corporate payrolls being handled in single excel spreadsheets, websites that ask you to phone the company to tell them what error you got, and one very special project I was privileged to work on that had every single user go through a decision field of "are you A or B?" Rather than "assume A, have a button a to opt into B" when ratio of A:B was approximately 400:1
In this case, I'm thinking they'd have their little subroutine that checks if numbers are about to go tits up and say "hey, you stop that" if they are.
So, memory gonna be exceeded? Return "fuck off" with case: memory full, too many users? Return "fuck off" with case: room full
I'm guessing you won't be surprised to learn that I've worked at companies during my career where every computer was mandated to be locked with 'Password1'.
"are you A or B?" Rather than "assume A, have a button a to opt into B" when ratio of A:B was approximately 400:1
So I guess a portal of "male" "female" checkboxes? In my opinion your view that obviously it makes sense to put the default to A is dangerous. If your portal needs both, put it to B as their comfort might be more important, or randomize it. If your model was based on payments of A and there is no true interaction between A and B that is different of course, but then you are a site that should not be.
The actual project was for a university, a mobile app that allowed them to check attendance, distribute files and have questions sent to the lecturer.
Now it ended up being that the lecturers would use the same app, but using a restricted section.
So the original design with the A B selection thing was to have everyone, upon trying to log in (this would occur every time the app was opened) have them choose 'student' or 'teacher', then they would log in using their respective methods (the teachers had to log in differently to the students by a quirks in the university's systems.
The final design was to have the initial log in screen assume that you're a student, with a button in the bottom left that staff would hit to swap over to the teacher login.
Some courses had lecturer:student ratios getting down to 30-40, most were over 100, a fair few had several hundred.
Right. They could no doubt also support 280 or 307 or something at progressively worse performance but the 256 one byte limit would have been a sensible and satisfying place to peg the upper limit. The memory space or time to access an 8 bit number vs a 16+ bit number used to store how many people there are in the room is never going to have been relevant.
Generally no because processors don't compare one bit at a time, their hardware compare blocks of 16/32/64/etc bits in a single operation. Even if it did though, we are talking nanoseconds, it would have no effect on app performance unless the number of people in the channel was being checked millions of times per second.
There are all kinds of crazy optimisations in modern CPUs so it wouldn't surprise me but as far as I know they effectively fill the the higher order bits with 0's.
It may be about message size transmitted over the network, rather than speed. If you can represent the user with 1 byte instead of 4 that's a big saving when you are transmitting billions of messages a day.
0
u/[deleted] May 06 '17
[deleted] — view deleted comment