1, 2, many development

When developing, sometimes you might find yourself repeating things within the same context. I generally try and follow a one, two, many system for a rule on when to stop just adding on to something and refactor / try an approach that makes it easy to scale.

This isn't just necessarily related to code, it could be processes you execute when performing a task.

The Walpiri are a tribe that use a one-two-many counting system.

Consider that when you do something, once is fine, twice is okay, but as soon as you go past that, assume it's going to be many.

I work with multi-tenanted systems at work. We might have to run a command for a tenant on the system. For this example, let's say we have to migrate the database of each tenant on a deployment (each tenant has a separate database).

We might have a script in our deployment process that performs the following:

php bin/console --env=tenant_one doctrine:migrations:migrate

That's what we need to do when our application is running for a single tenant.

When tenant number two comes along, we decide to add a second line to the deployment script to ensure the second tenant gets migrated:

php bin/console --env=tenant_one doctrine:migrations:migrate
php bin/console --env=tenant_two doctrine:migrations:migrate

But now when tenant number three comes along, rather than adding a third line (and a fourth and a fifth etc), consider how you'd scale this for many.

You could store a list of tenants in a central registry, or retrieve the tenants you have on the system from configuration, and iterate through them. Running the command for each tenant one after another. Or you could use something such as GNU Parallels or xargs to run these processes in parallel during the deployment.

But once this is done, it doesn't matter if you have three tenants or three thousand tenants, it's no more work for you to perform the task.

The first time you do this, it might not have been worth spending the extra time to write an approach for the many. The same with the second time, but that's the limit - after that is when you take the approach of "this has to work for many more"

You have to set a limit somewhere, and we set ours at one-two-many.