Years ago, I bought some software. Its serial number had quite a few digits. I found out later that I had been the first customer. I guess the idea was that customers might be more confident to jump in the water, if they saw others there already.

This is a technique used in other ways too. For instance, when opening a new checking account, it’s common to start with an arbitrary number for the first check. And often new businesses will start with an arbitrary invoice number.

It used to be common for businesses to refuse to take a check if it had a low check number, the assumption was the account was new and had a higher chance of bouncing. Eventually the banks let you pick or set high numbers so you wouldn't have to deal with that inconvenience.

There's a fair number of ecommerce setups that default to numerically ascending order numbers also.

About 15 years ago I was part of a team of four developing a VoIP platform. When we were about to release we realized that our first customer would be upset if they knew they were actually the first customer. So each one of us said a number and our first user had an ID similar to 1003912 :)

I remember getting a large-ish IBM storage product 10-15 years ago with a serial number of 1. They actually updated it once someone realized!

Hey, author here :)

Normally I'd agree with you, but in this case we're explicitly dealing with external IDs that we want to be incrementing.

Our internal IDs and API IDs actually follow a totally different approach, and hold no meaning other than as a reference :)

You would run into this problem even if you aren't using the database number as your primary key. We don't want to force the user to generate the incident handle (slowing down incident creation) so a sequence of number is useful.

Generating the sequence in application logic can make it challenging to guarantee we don't duplicate numbers if two requests come in at once (you don't want locks/global synchronous state in the application if you can avoid it), so having the database generate them is a good fit.

Customer IDs should have at least one or two checksum digits to help spotcheck for data entry errors anyway.

Indeed, if you skip this you're going to have a weird "bug" some time in the next years where a customer accidentally got the ID wrong and the system accepted it.

Google Analytics either doesn't do this or got really unlucky. But some day I had to troubleshoot an issue where the data for a totally unrelated website ended up in someone's GA data set. Not just the usual spam, but millions of visits to the wrong website which had an account ID very similar to the client's.