[YZF]

This will be somebody else's problem? Ehm, no it's not.

- When the bridge collapses I'll be managing someone else.

- When they find out this airplane has critical design flaws I'll be managing someone else.

- When this software I'm working on is hacked I'll be managing someone else.

[emilsedgh]

It's not a matter of who's problem it is. It's just that a scale-able architecture in most cases is a premature optimization. When building a product, scalability is only one aspect. And in case of most startups and companies, amongst the smaller ones.

I personally interview a lot of people and if they start proposing microservices or k8s or anything trendy like that (before having context), I consider it a negative point.

When hiring, I want someone to take a look at a busines problem, break it down into a smaller pieces. Most of the times, the most important engineering work is coming up with the right data models/data structures.

So yeah, maybe the architecture I have now wont scale up. But at least it'll get the business going. Years later when there are more resources, the software could be rewritten or whatever.

Also, you'r example mentioned "software being hacked". I never said undermine security. Security should always be taken seriously. Security is not a premature optimization. Scalability is.

[webmaven]

> Security is not a premature optimization

There are plenty of situations where decent security is a premature optimization too. For example prototypes or proofs-of-concept that are only intended to demonstrate or benchmark a capability. The sort of thing where, even if you did insist on making it 'secure' the username/password would be admin/admin.

[YZF]

I wasn't commenting on whether scalability is important or not. I was commenting on that mindset: "When that matters, I won't even be managing the person whose problem that is."

What you said all sounds reasonable. Sure, don't build something scalable if you've figured out you want something quick to prove your market and you're ok with tossing it all away or if you'll never need the scale. These are not the same thing. But this will be somebody else's problem? I don't want that guy on my team... Something someone told me a long time ago, write code like the guy that takes it over from you is a psychopath and has your address.

[anamax]

All bridges have a capacity limit.

"Doesn't scale" doesn't imply "inadequate."

Overbuilding is waste.

[Tanjreeve]

Software isn't bridges though. If you run into scaling issues if you're lucky it's just a case of swapping out a database for a bigger one. More likely it isn't just that though and being able to do things like scale up distributed workers coherently with a change of a config file requires upfront thought and design that YAGNI would say isn't necessary. People just breezily saying "we can optimise it later" for a scale up of orders of magnitude are nearly always wrong. I'd argue Reddit is a perfect example of a site that's clearly running into scaling issues but are locked into an architecture with few escape hatches built in

When a bridge fails it'll just fail. When software runs into a scaling limit it'll degrade and fall on its arse constantly and be absolutely terrible as long as it takes for the software team to completely rework their entire architecture often having to learn completely new technologies.

[anamax]

No, software isn't bridges. When bridges fail, people die. When reddit crashes, people take a piss and pet the cat.

I don't know the relevant details about reddit but the assumption that the early reddit people could have easily built something more scalable yet there are tech reasons why the later people, with far more resources, can't.

As to the assumption that one knows the important bottlenecks 2-3 orders of magnitude in advance, that's just wrong.

"late answers are wrong answers" isn't just for real-time. That applies to products as well as signals.

Technical debt is not necessarily a bad thing.

[webmaven]

Your examples aren't equivalent. You're comparing the failure of a prototype or proof-of-concept under stress to the failure of production models under expected conditions.

The real risk you're incurring by deploying a prototype to production until traction is demonstrated and scaling becomes an issue is that deferring the design of the 'real' system risks succumbing to second-system syndrome and prematurely trying to make it a 'platform'.

Roughly, the first version just has to work, the second has to scale, and the third (assuming you get there that soon) is the one that starts needing to be refactored/generalized into various reusable subsystems.

[anamax]

The second doesn't (necessarily) have to scale.

It has to handle the projected load, with some safety margin.

"projected until when?" you ask?

Well, your projections will be wrong. And, your needs will change, which means that you're going to be changing the system anyway.

That's where judgment comes in.

Suppose that each customer is worth $10/month and that the "not scalable" version can handle 1M customers. That's at least $5M MRR when the system is at 50%.

If the scalable version takes significantly longer to develop, you might choose to put it off until you have more money/resources, especially since there will probably be other changes. (And, you don't know where the actual bottlenecks are.)