Numbers are a funny thing, especially when you run out of them. A while ago, I was sitting in a meeting discussing making a series of marketing messages with numerical priorities. I opened my mouth to issue a warning when someone on the team said, “We should assign these messages priority values as multiples of ten for future consideration.” My heart! I blinked back some tears of gratitude, and the meeting continued.
Assigning numbers to things creates some unusual problems. I recall working on a team long ago where we had a series of popups with assigned priorities. The priorities were assigned numbers, with zero being the highest priority. The priorities were also assigned in software by complicated marketing rules, meaning changing these values introduced risk. It should come as no surprise to anyone that, eventually, there was a more important message to send to the user than the one assigned to the highest priority.
The proposed “solution”, which I have seen repeated on more than one occasion, was to create a new class of marketing popups with a higher priority than the existing chain of popups. For fun, let’s call that the super popup.
For a period of time, everything was fine. As with the original popups, a higher-priority popup would eventually be sent to the application’s users. The original popup product manager and the super popup product manager had already moved on to other teams or jobs. The new product manager put together a design for a new system of popups that would be checked before the super popup and the original popup—the hyper popup!
I was in the room when this was announced to the engineering team. You could literally hear souls shattering and sadness exponentially growing throughout the room. One team veteran calmly pointed out that this would be the third time we are building a prioritized popup messaging system and that this one, much like the others, would eventually become obsolete. We would eventually need to display a higher-priority message after popups, super popups, and hyper popups.
There is a lot to unpack here. The first is that decreasing numbers for increasing priorities is a very dangerous pattern. You quickly run out of positive numbers that are less than zero.
The second thing is that while there is something psychologically satisfying about turning increasing priorities into decreasing positive integers, it is upside down and backward. “This is a priority zero!” is a much more satisfying declaration than “This is a priority three hundred and seven!”
In the first paragraph, a wise soul declared that it might be good to future-proof the system by making things multiples of ten. Why stop there? Why not a multiple of one hundred or even one thousand? If you are averse to increasing numbers to represent increasing priorities, you can buy yourself some time by spacing these numbers out into larger values this way.
This is one of those design mistakes that most people learn about by doing once. The first time I had to build a set of prioritized messages, I made this mistake and ran out of numbers smaller than zero. The message numbers were C++-based #define assignments, which meant a quick edit pass fixed the problem. If you are working on a legacy system with multiple client and server codebases outside your control, you would need to do something different here.
That’s it. That is the whole post. This is probably as close to actual coding or architecture advice as I am going to give on my blog. Ideally, you do not have to inherit a problem like this in your career. Also, if you build a set of prioritized items, you pick magic numbers like 1000, 2000, 3000, 4000, 5000 vs 0, 1, 2, 3, 4 for priorities.
The eventual person who has to inherit your feature will thank you for it. See you next week!
