3 ms·

Why not just soft limit it? If you think a vanishingly small percentage of people are going to run into the limits, just put a note "You've reached the end of t

Why not just soft limit it? If you think a vanishingly small percentage of people are going to run into the limits, just put a note "You've reached the end of the internet! Please click here to email me and let me know you've found it" and wait until you get a response, and do the cost-benefit analysis then.

zdw 13y ago
Putting an artificial limit and forced human interaction into software is problematic. I encountered a database once where there was a hidden limit on the number of categories for customers. Specifically, you could add more categories over some very low number (16 or 20) the program would fail to open - it would hang on a loading screen. We didn't have source, so we ended up having to find and pull the developer out of retirement (it was a 16-bit windows crystal reports program), who found the error after looking at it for a few weeks. It was a one line change that bumped up that limit to something like 1000. Most of the time the limit you may have aren't realized, and you assume that the programmer is smart enough to note and communicate with the user about all possible limits. Don't cripple your software. It's better if it runs poorly than it not running at all.
mikeash 13y ago
Poor performance with large numbers of items is just such a soft limit, except instead of artificially disallowing you from doing what you want, it degrades gracefully. Taking that into account, your proposed approach would be: don't worry about performance on what you consider to be abnormally large data sets, and instead just wait for people to e-mail you about it, and you can decide if it's worth fixing then. And there's nothing wrong with that approach, I think! Although I think a lot of developers rely on it too much. But it's better than putting in an artificial roadblock.
- jaggederest 13y ago
  Well, my point is that you add an explicit call to action for it - my experience has been that <1% of people will email/contact about a problem. Most people just abandon it right there, so a big 'This is a problem' button helps.

zdw 13y ago

Putting an artificial limit and forced human interaction into software is problematic. I encountered a database once where there was a hidden limit on the number of categories for customers. Specifically, you could add more categories over some very low number (16 or 20) the program would fail to open - it would hang on a loading screen. We didn't have source, so we ended up having to find and pull the developer out of retirement (it was a 16-bit windows crystal reports program), who found the error after looking at it for a few weeks. It was a one line change that bumped up that limit to something like 1000. Most of the time the limit you may have aren't realized, and you assume that the programmer is smart enough to note and communicate with the user about all possible limits. Don't cripple your software. It's better if it runs poorly than it not running at all.

mikeash 13y ago

Poor performance with large numbers of items is just such a soft limit, except instead of artificially disallowing you from doing what you want, it degrades gracefully. Taking that into account, your proposed approach would be: don't worry about performance on what you consider to be abnormally large data sets, and instead just wait for people to e-mail you about it, and you can decide if it's worth fixing then. And there's nothing wrong with that approach, I think! Although I think a lot of developers rely on it too much. But it's better than putting in an artificial roadblock.

jaggederest 13y ago
Well, my point is that you add an explicit call to action for it - my experience has been that <1% of people will email/contact about a problem. Most people just abandon it right there, so a big 'This is a problem' button helps.