5 ms·

> Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now. This. What happened to "make it work then

> Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now. This. What happened to "make it work then make it scale" ?

beagle3 10y ago
> This. What happened to "make it work then make it scale" ? The fact that it is wrong (or rather, incomplete) It should be "make it work with a clear path to scaling, then make it scale" - that's true with respect to both software engineering and business plans. It's the same with "premature optimization is [the|a root of [all]] evil" - Premature optimization is a waste of time and often paints you into a corner. However, if you don't think about the bottlenecks and how to optimize them in advance, you more often than not find later, when profiling, that there are not enough hotspots, and the performance is "lost" all over the place.
- lmm 10y ago
  Not my experience at all. Systems that were designed as simply as possible can be unpicked and made scalable - it takes time and effort but it's doable. Systems that were designed to be scalable are much worse, because you have to undo all of that work first before you can start actually making them scalable.
  - beagle3 10y ago
    Simpler systems are easier to scale than more complicated ones, for sure - but things like making sure that your database is easily shardable are often cheap (even free) before you start, and might be extremely expensive later on -- I'm familiar with a project that eventually spent a few hundred thousand dollars on some high performance database (Oracle RAC or something, don't remember exactly), where -- if the database schema was shardable in advance -- they could have been ok with 10-20 cheap machines running MySQL. And I remember an earlier project that had to be completely rewritten in the early '90s because at the time, Oracle couldn't yet scale even throwing money at it (and DB2 reportedly could - but the required Mainframe was not an option). Simple is often best, yes. But not oblivious-to-the-future simple.
  - allengeorge 10y ago
    Perhaps you guys are talking about different things? There are certain architectural decisions (schema design, etc.) that can dramatically impact future scalability. Sometimes if you implement it the "simple" way the design can very quickly reach its limits and have to be replaced. And, honestly, sometimes you've done variants of the same problem enough that you know where some of the bottlenecks are inevitably going to be - so why not design them out right at the start?

> Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now. This. What happened to "make it work then make it scale" ?

beagle3 10y ago

> This. What happened to "make it work then make it scale" ? The fact that it is wrong (or rather, incomplete) It should be "make it work with a clear path to scaling, then make it scale" - that's true with respect to both software engineering and business plans. It's the same with "premature optimization is [the|a root of [all]] evil" - Premature optimization is a waste of time and often paints you into a corner. However, if you don't think about the bottlenecks and how to optimize them in advance, you more often than not find later, when profiling, that there are not enough hotspots, and the performance is "lost" all over the place.

lmm 10y ago
Not my experience at all. Systems that were designed as simply as possible can be unpicked and made scalable - it takes time and effort but it's doable. Systems that were designed to be scalable are much worse, because you have to undo all of that work first before you can start actually making them scalable.
- beagle3 10y ago
  Simpler systems are easier to scale than more complicated ones, for sure - but things like making sure that your database is easily shardable are often cheap (even free) before you start, and might be extremely expensive later on -- I'm familiar with a project that eventually spent a few hundred thousand dollars on some high performance database (Oracle RAC or something, don't remember exactly), where -- if the database schema was shardable in advance -- they could have been ok with 10-20 cheap machines running MySQL. And I remember an earlier project that had to be completely rewritten in the early '90s because at the time, Oracle couldn't yet scale even throwing money at it (and DB2 reportedly could - but the required Mainframe was not an option). Simple is often best, yes. But not oblivious-to-the-future simple.
- allengeorge 10y ago
  Perhaps you guys are talking about different things? There are certain architectural decisions (schema design, etc.) that can dramatically impact future scalability. Sometimes if you implement it the "simple" way the design can very quickly reach its limits and have to be replaced. And, honestly, sometimes you've done variants of the same problem enough that you know where some of the bottlenecks are inevitably going to be - so why not design them out right at the start?