Hacker News Reader

Comment by dagorenouf | Hacker News Reader

I built my startup 4 years ago with a combination of react + aws + gatsby + hasura. I thought this would be great for performance and scale. Fast forward to today, I spend at least 2x as much time to code a feature than if I had just stuck with a simple rails stack, and the scale I imagined never happened. Now rebuilding everything with rails so I can ship faster and focus on growing the product, not making engineering prowesses.

View on HN

Considering most of the times the startup at hand will fail anyway and the planned scale will not happen, building the initial architecture to be "web scale" is a perfect example of YAGNI.

I had a similar experience, and it was a great lesson.

We used to write software for pretty high-traffic systems using what is now underpowered CPUs, less RAM, and antiquated databases. It should be easier now, NOT harder. Most of development I see today is resume-driven and not based in any pragmatism.

Building for scale from day 0 is a recipe for disaster. You should've seen that coming.

You suggest people should refactor later on when needed?

There comes an inflection point in a startup when you have to move from MVP to scale, and there are two different kinds of tech and two kinds of people for each stage

Yea, you identify bottlenecks and refactor those as needed (with something like rails it's pretty easy to change out parts of your system while retaining the rails core). Every business will have different bottlenecks and it's very hard to identify them before you start accumulating customers and see how they are using your app

That actually makes sense

Cost of capital for a startup that is succeeding is almost always far higher early on, so you want to focus on moving fast over scaling as long as you can scale enough to get to big enough raise to throw far more resources at the problem.

Literally yes. Outside of a few very basic common sense optimizations (avoid n+1 queries, use indexes liberally, maybe sprinkle some caching on heavily used endpoints) you should focus entirely on shipping features with the knowledge that your product and by extension your code almost certainly won't look anything like it does now in 18-24 months.

If you are fire-fighting production issues at scale all the time with the original version, you may find yourself out-of-capacity for a refactoring/rewrite. After experiencing this terrible state of affairs, I prefer getting performance and robustness (mostly) right the first time.

this absolute is a little ignorant. For some products the scalability is the core competitive advantage. He can't engineer it in after the fact.

It's literally Donald Knuth:

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”

Can you give some examples of such products?

A database would be an obvious example. Analytics platforms and message queues are another couple that come to mind.

You can't patch the kind of performance you need for these products after the fact, it needs to be baked into the architecture.

I think the authors above just meant that you don't know if your product will even get there so instead of over-engineering your stack and prepping for every possible scenario you'd take Just-in-time approach and conquer the problems when they come at you.

I haven't been able to apply to a real project yet, but I like the idea of building to refactor.

You execute for today, but make it easier to replace parts on the future

doubling down on premature optimization and chasing the new hotness with a ground-up rebuild... I hope that works out.

The "new hotness" of 2005?

Reply on news.ycombinator.com