Preemptive Pluralization is (Probably) Not Evil

Listen to audio accompaniment

Before you write any code — ask if you are likely to need multiple kinds of the thing you are coding.

A few common examples to illustrate:

• You assume that one team has many users, and correspondingly, one user belongs to one team.
  • Eventually, you find that a user may need multiple teams.
  • This is actually fantastic for your business!
  • But you are depressed because you now have to spend 3 months refactoring every line of code and database schema that assumed the one-to-one mapping.
• You assume that loading state only has two states — true / false — so you make a boolean isLoading variable
  • Then you realize you need to track error state, so you do, with isError. You do some work to make sure the 4 combinations of states behave intuitively. You write tests for each of them like the good developer you are. Of course.
  • Then you realize you need an isCanceled state for long running jobs. 8 state combinations and counting...
  • Eventually you realize every addition or modification takes exponentially longer to account for each edge case. It's hard to even tell if you've covered them all. Most don't.
  • The solution is explicit state machines - but at this point you're too far in to justify a rewrite.
• Internationalization. If you winced at that, you know the pain.

You can listen to Ben Orenstein of Tuple discuss this on my mixtape:

I've done this refactoring a million times. I'll be like, I thought there would only ever be one subscription team, user plan, name, address , and it always ends up being like, Oh, actually there's more. I've done this a million times. I always never go the other way. What if you just paid the upfront cost of thinking "This is just always a collection"?

Donald Knuth is famous for noting that Premature Optimization is the Root of All Evil. I am very sympathetic to the appeal to simplicity — if "You Ain't Gonna Need It", then don't use it. But I think Preemptive Pluralization — projecting forward into hypothetical situations when you need N types of a thing — is exempt, even though you are literally optimizing for a future you don't currently live in.

It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2. This is a fundamentally under-appreciated nonlinearity. In other words, Preemptive Pluralization can make the difference between "sure, I'll add that today" and "this is going to take us 2 months and we'll introduce merge conflicts with every other in-progress feature."