That won't scale! Or present cost vs. future value.

Oftentimes, we choose between an easier solution A and a more robust solution B.

Developers tend to pick the one that is more robust. When presented with an alternative, they usually exclaim things like "That won't scale!" or "But what if in the future, there will be X?"

It's a hard argument to beat.

First, it makes them look like "seasoned developers." After all, they foresee things and aspire to think through all the possibilities.

Second, it's because there's no data to argue with. They appeal to some point in the future when something might happen. But what are the chances that it will happen? Nobody knows.

Is it likely that we will have 100x more users next month? It's possible. Is it likely that a comet will fall and destroy half of the world's population? It can happen. Should we cover all possibilities?

So how do we flip this conversation to make it more pragmatic? How do we make the best decision given the data we have today?

I find the following simple question helpful:

What will be the additional cost of changing our solution from A to B in the future compared to implementing B today?

Surprisingly, in most cases, the cost of change is close to zero.

Here are some examples:

Example 1:

You have a simple webpage that collects user emails.

A: Let's just put them into a text file.

B: That won't scale! We need a database! Imagine if our file grows to hundreds of thousands of lines. What if you need to delete a line? What if you need to find if an email exists? Every time, you will have to scan through the whole file, which is very slow!

A: OK, so let's start today with a text file and switch to a DB in the future when (and if) it becomes slow. What is the additional cost, and how hard will it be?

B: Well, we'll just need to copy the emails from the file into a database table...

A: So it's settled then!

Example 2.

We need to check if the user can create an app.

A: Let's start with a method on a user “can_create_app”

B: Not on my watch! We need a full-blown role-access system. Users will probably have many access rights, roles, and groups. Oh, and they all should be hierarchical! Oh, and it must be a dedicated microservice with REST API!

A: Ummmmmm, hold on. What will be the cost of implementing it in three months vs. today?

B: Well, it'll be mostly the same, plus we will need to change this `can_create_app` method.

A: Sounds good to me.