Don’t confuse forward thinking with premature optimisation

Premature optimisation is the root of all evil. We’ve all heard it, and we all understand what it is. It’s adding unnecessary complexity, and solving use cases which aren’t guaranteed to exist moving forward, or ever.

It’s easy to confuse forward thinking with premature optimisation.

What’s forward thinking?

Forward thinking is solving a problem in a way which will allow future use cases to be solved on-top of easily.

You’re not just solving the problem to leave at 5 o’clock, you’re solving the problem and letting everyone else leave at 5 o’clock on D-day (deploy day).

Deployed with no hitches!

To not confuse the two, when should you be worried, and when shouldn’t you?

You should be worried when

• Your solution is taking longer than a more exact approach.
• You’re solving for a general case, when you only have one, or very few provided.
• It will increase the complexity of the logic.

If you’re ticking these boxes, maybe you’re prematurely optimising your code?

yikes

You have to accept that sometimes your solution may not be as generalised, and flexible as you want. But understand that if you ever need to add another case to solve for, you will have the time then to improve on what you have.

So, on the other hand then,

Don’t be worried when

• The forward thinking approach takes the same amount of time to implement.
• You’re allowing your solution to be extensible, given a likely update/change to the conditions.

An example,

You’re provided an address as a single string. You need to assign the address into a variable, billingAddress1.

However, if there is a line break within the address, you’ll need to assign that to a separate variable, billingAddress2

const address = "123 fairytale lane, farquad /n Far far away"

A valid solution would be to split the string by the line break, put the first substring into billingAddress1, and the second into billingAddress2

const address = "123 fairytale lane, farquad /n ,Far far away"
// creates an array split by the /n
const splitAddress = Address.split(“/n”)
const billingAddress1 = splitAddress[0]
const billingAddress2 = splitAddress[1]

This has solved the problem, but it does leave a potential issue. What happens if there is a second line break?

Oooh

yfw you didn’t think of a second line break..

Wait, is this premature optimisation?

There isn’t this case to solve for, why are you adding this as a possibility?

Bear with me okay?

We’re not going off on the deep end here! I promise.

But instead of explicitly calling the first and second indexes in the array, why not instead find the index of the line break and assign the addresses respectively?

const address = "123 fairytale lane, farquad /n ,Far far away /n 600"
const addressIndex = address.indexOf("/n");
const billingAddress1 = address.substring(0, addressIndex);
const billingAddress2 = address.substring(addressIndex, address.length);

We’re not adding complexity, it’s not taken any longer to solve, yet we’re now avoiding the case where another line break is added to the address string which would cause us to lose data

However, these are the critical points where you need to identify. Is there another valid solution you can think of, and how long it will take to implement?

In this case it’s trivial thanks to it being contrived, but what about in yours?

Be wary of premature optimisation, but be wary that it’s not the same as thinking ahead. Forward thinking will save you!

What do you think?