4 ms·

> Imagine traffic increases exponentially, and this average team setup an average website, with a data storage engine that’s hard to shard, hosting that doesn’

by sbov 9y ago

> Imagine traffic increases exponentially, and this average team setup an average website, with a data storage engine that’s hard to shard, hosting that doesn’t have enough redundancy, version control without proper backup, no CI environment, and no monitoring. How productive will those 10 coders be if they are spending all their time putting out fires? The 10x developer may or may not be a myth, but the idea that you can design your system for exponential traffic increase without any tradeoffs is not engineering, it's fantasy. I guess "no silver bullet" is dead in the year 2017.

nikanj 9y ago
Nowadays we create silver buckshot from microservices. Scalability problems? Just add more services!
nostrademons 9y ago
This was a weird example to me because anyone who's dealt with exponential traffic increase knows that you will end up rewriting several times. Dean's Law: "Plan for 10x growth, but expect to rewrite before 100x": https://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf https://static.googleusercontent.com/media/research.google.c... (page 11) Additionally, one thing the best programmers I know have all drilled into me is don't write code speculatively. You should write code because it solves the problem you have now, not the problem you think you're going to have in a couple years. It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.
- deleted 9y ago
  [deleted]
- jaimebuelta 9y ago
  THIS: It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way. Code evolves as the problem evolves and NEEDS to be adapted. Is impossible to foresee the future.
  - wolco 9y ago
    I disagree forward looking software design with patterns that could be reused for scaling is the right approach.
  - AstralStorm 9y ago
    This approach generates regular expensive rewrites that a typically slightly more flexible and/ or modular solution would avoid. The key words are slightly. The trap is to overgeneralise or apply a technology or approach like a hammer without understanding its limitations. Out is impossible to foresee the future, but trivially easy to see current requirement and extrapolate a bit.
    - nostrademons 9y ago
      The problem is that you usually don't know in which direction that flexibility will be required. I can't count the number of times I've "trivially extrapolated a bit", showed my boss or VP, and then gotten back "actually, we don't want to put any more effort into X. I appreciate how you went above-and-beyond, but priorities have changed, and it turns out we really want Y instead," followed by much handwringing when I go back to the code and find out that the flexibility and modularity that I built into the system expecting we'd do more of X next actually impedes progress in making it do Y. Lest you think this is just bad management - I work for myself now, on a startup, and I have the same problem (or would had I not beaten this habit out of myself). Very often, I'll think "Woah, there's a much more elegant approach that will let me do Y and Z much better at relatively low engineering cost", and then I'll finish X, and put it in front of potential users, and they'll say "Actually, we don't care about Y and Z at all...why would we want them? We want to do A and B instead", where A and B take the product in a completely different direction from Y and Z. There is a place for planning a little bit ahead, but that place is to plan to reach the next milestone as quickly as possible. You should never try to guess what the milestone beyond that is without checking in with users or management.
  - hinkley 9y ago
    I would go even farther here. Without an established culture of adaptation and refactoring, your team lacks the perspective necessary to know what the 'right' architecture is. The paradox here is that people who could extract the most benefit from a rewrite don't have to ask for one, and those least equipped to benefit constantly blame their problems on the lack of one. At the end of the day, the rewrite or 'perfect architecture' is a dodge. You get to be left alone for 4-8 months with nobody hassling you, which means the perverse incentive is: rewrite = peace and quiet

by sbov 9y ago

nikanj 9y ago

Nowadays we create silver buckshot from microservices. Scalability problems? Just add more services!

nostrademons 9y ago

This was a weird example to me because anyone who's dealt with exponential traffic increase knows that you will end up rewriting several times. Dean's Law: "Plan for 10x growth, but expect to rewrite before 100x": https://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf https://static.googleusercontent.com/media/research.google.c... (page 11) Additionally, one thing the best programmers I know have all drilled into me is don't write code speculatively. You should write code because it solves the problem you have now, not the problem you think you're going to have in a couple years. It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.

deleted 9y ago
[deleted]
jaimebuelta 9y ago
THIS: It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way. Code evolves as the problem evolves and NEEDS to be adapted. Is impossible to foresee the future.
- wolco 9y ago
  I disagree forward looking software design with patterns that could be reused for scaling is the right approach.
- AstralStorm 9y ago
  This approach generates regular expensive rewrites that a typically slightly more flexible and/ or modular solution would avoid. The key words are slightly. The trap is to overgeneralise or apply a technology or approach like a hammer without understanding its limitations. Out is impossible to foresee the future, but trivially easy to see current requirement and extrapolate a bit.
  - nostrademons 9y ago
    The problem is that you usually don't know in which direction that flexibility will be required. I can't count the number of times I've "trivially extrapolated a bit", showed my boss or VP, and then gotten back "actually, we don't want to put any more effort into X. I appreciate how you went above-and-beyond, but priorities have changed, and it turns out we really want Y instead," followed by much handwringing when I go back to the code and find out that the flexibility and modularity that I built into the system expecting we'd do more of X next actually impedes progress in making it do Y. Lest you think this is just bad management - I work for myself now, on a startup, and I have the same problem (or would had I not beaten this habit out of myself). Very often, I'll think "Woah, there's a much more elegant approach that will let me do Y and Z much better at relatively low engineering cost", and then I'll finish X, and put it in front of potential users, and they'll say "Actually, we don't care about Y and Z at all...why would we want them? We want to do A and B instead", where A and B take the product in a completely different direction from Y and Z. There is a place for planning a little bit ahead, but that place is to plan to reach the next milestone as quickly as possible. You should never try to guess what the milestone beyond that is without checking in with users or management.
- hinkley 9y ago
  I would go even farther here. Without an established culture of adaptation and refactoring, your team lacks the perspective necessary to know what the 'right' architecture is. The paradox here is that people who could extract the most benefit from a rewrite don't have to ask for one, and those least equipped to benefit constantly blame their problems on the lack of one. At the end of the day, the rewrite or 'perfect architecture' is a dodge. You get to be left alone for 4-8 months with nobody hassling you, which means the perverse incentive is: rewrite = peace and quiet