> But sometimes it IS better to think a few steps ahead, rather than building a new system from scratch every time things scale up.

The problem is knowing when to do it and when not to do it.

If you're even the slightest bit unsure, err on the side of not thinking a few steps ahead because it is highly unlikely that you can see what complexities and hurdles lie in the future.

In short, it's easier to unfuck an under engineered system than an over engineered one.

I agree with thinking a few steps ahead. It is particularly useful in case of complex problems or foundational systems.

Also maybe simplicity is sometimes achieved AFTER complexity, anyway. I think the article means a solution that works now... target good enough rather than perfect. And the C2 wiki (1) has a subtitle '(if you're not sure what to do yet)'. In a related C2 wiki entry (2) Ward Cunningham says: Do the easiest thing that could possibly work, and then pound it into the simplest thing that could possibly work.

IME a lot of complexity is due to integration (in addition to things like scalability, availability, ease of operations, etc.) If I can keep interfaces and data exchange formats simple (independent, minimal, etc.) then I can refactor individual systems separately.

1. https://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork

2. https://wiki.c2.com/?SimplestOrEasiest

>But sometimes it IS better to think a few steps ahead

The trouble is by the time you get there you will discover the problem isn't what you expected and it will all have been wasted effort.

https://en.wikipedia.org/wiki/You_aren't_gonna_need_it

Yes sometimes. But how can you know beforehand? It’s clear in hindsight, for sure.

The most fundamental issue I have witnessed with these things is that people have a very hard time taking a balanced view.

For this specific problem, should we invest in a more robust solution which takes longer to build or should we just build a scrappy version and then scale later?

There is no right or wrong. It’s depends heavily on the context.

But, some people, especially developers I am afraid, only have one answer for every situation.

IPv6 is arguably a good example of what happens when you don't do the simplest thing possible. What we really needed was a bigger IP address space. What we got was a whole bunch of other crap. If we had literally expanded IPv4 by a couple of octets at the end (with compatible routing), would we be there now?

It can be hard enough to fix things when some surprise happens. Unwinding complicated “future proof” things on top of that is even worse. The simpler something is, the less you hopefully have to throw away when you inevitably have to.

IPv4 vs IPv6 seems like a great example for why to keep it simple. Even given decades to learn from the success of IPv4 and almost a decade in design and refinement, IPv6 has flopped hard, not so much because of limitations of IPv4, but because IPv6 isn't backwards compatable and created excessive hardware requirements that basically require an entirely parallel IPv6 routing infrastructure to be maintained in addition to IPv4 infrastructure which isn't going away soon. It solved too far ahead for problems we aren't having.

As is IPv4s simplicity got us incredibly far and it turns out NAT and CIDR have been quite effective at alleviating address exhaustion. With some address reallocation and future protocol extensions, its looking entirely possible that a successor was never needed.

But a 128 bit identifier maybe was not the best choice when ipv4 was in the works... maybe 64?