Embracing Hard Limits
All software needs limits. Almost every part of any software needs a hard limit. At least every part that deals with lists. In most languages and databases, this means arrays and strings.
This sounds obvious, but I suggest every engineer reading this open up their codebase and look around. Surely you have length validations here and there, but if you never dedicated half a day to go over all lists aiming to set a limit on each, you likely have several cracks remaining.
I do not mean obvious user-facing limits, such as “3 seats” or “15 days email history“ on our Free plan. I mean limits that 99% of users will never hit. For instance, pasting several paragraphs in your email subject instead of the body. Or likewise, typing the “Notes” of a contact in the “First name” field. Or everyone’s infinite loops you’ll be plagued with as soon as you introduce a public API.
The only scenario where you do not need a hard limit is when a list is always accessed through pagination. After all, pagination means there is already a LIMIT involved.
Embrace Hard Limits
I love hard limits. I love knowing they are there. I love introducing new ones with any new feature. Hard limits are key to keeping me asleep at night.
They are also low-effort; they don’t need public documentation. You naturally implement decent error messages for the few outliers that will hit them, but nobody needs to have these limits in mind to plan whether they will affect their business.
You should even make it a requirement to not have to disclose these limits. If you start seeing a significant enough number of exceptions, you’ve most likely just set it too low. The point is not to annoy or restrain users; it’s to avoid crashes. Increasing one limit from 500 to 1000 will not cause your app to crash, but it may make the difference between one user hitting that limit every month instead of every day.
It’s also an occasion to remember that our world is diverse. Stay humble, accept and embrace the fact that some of your customers will have use cases you never expected. Don’t fall into the trap of accusing people of misusing your software.
One day, we did have an organization hit a roadblock due to a limit and they emailed us. They needed to set over 25 custom fields on a contact. Did we ask them to explain their situation and figure how they could adjust their usage? Of course not. We had set that 25-limit arbitrarily at first so we could just as well increase it to 50. Problem solved!
Avoid Bikeshedding
I suggest you constraint yourself to a short list of numbers for all your limits:
1 • 5 • 10 • 50 • 100 • 500 • 1000 • 5000
These are the easiest to remember for anyone. There is also a wide enough gap between each to make decisions easy. It’s wasteful to wonder whether 100, 200 or 300 is appropriate. Any doubt 100 isn’t enough? Pick 500, that’s plenty!
“1” comes into play when used as KB or MB. What should be the max length of an HTML email body? I’m sure you’ll agree 1 MB is OK, given that’s roughly a Harry Potter book.
What size of JSON payload should our web server refuse to parse? Either 5 MB or 10 MB sounds great. The latter is what Amazon API Gateway uses.
When you reply to an email thread and we quote it under your response, where do we stop? 10 KB of quoted text for the win.
How many labels will you apply to that one conversation? I hope 100 is fine with you.
How many concurrent sessions do you need before you smell like multiple users not wanting to pay a fair price per seat? Never heard a soul needing more than 10.
The list goes on.
Hope you enjoyed this and will spend your next morning adding sweet limits all over your codebase. Do it, it’s fun! ✌️
