5 ms·
Building for scale from day 0 is a recipe for disaster. You should've seen that coming.
by AeroNotix 4y ago
Building for scale from day 0 is a recipe for disaster. You should've seen that coming.
- Alifatisk 4y agoYou suggest people should refactor later on when needed?
- shortrounddev 4y agoThere 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
- ativzzz 4y agoYea, 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
- Alifatisk 4y agoThat actually makes sense
- vidarh 4y agoCost 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.
- ascendantlogic 4y agoLiterally 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.
- lenkite 4y agoIf 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.
- skeeter2020 4y agothis absolute is a little ignorant. For some products the scalability is the core competitive advantage. He can't engineer it in after the fact.
- NhanH 4y agoCan you give some examples of such products?
- ZephyrBlu 4y agoA 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.
- andrewmutz 4y agoIt'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.”
- deleted 4y ago[deleted]
- throwaway445232 4y ago[flagged]
- kirso 4y agoI 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.