4 ms·

I find this argument very uncompelling. This product sounds like it never exited mvp if sql server free was to be good enough. I'll agree that at small scale

I find this argument very uncompelling. This product sounds like it never exited mvp if sql server free was to be good enough. I'll agree that at small scale there are lots of potential technologies. But it also makes me wonder what was so challenging here that they felt they had to keep swapping around. I won't speculate here. However I disagree with the premise. At scale this absolutely matters. Different databases have vastly different design goals or cap theorem attributes. You'd better pick the right on or it'll impact your customer xp.

falcolas 12y ago
> At scale this absolutely matters. So worry about it when you get to scale, not before. Most products and startups never reach the scale at which such basic technology choices matter; their time is better spent growing the company (adding user features, attracting new users, etc) than fighting with technology. MySQL was never designed to scale to the levels which Facebook and Google use them. And yet both companies are still using them today, even as the roles they use them in diminish as better technologies are brought to bear. Technology shortcomings can be worked around, so long as you're still in business.
- marcosdumay 12y ago
  > So worry about it when you get to scale, not before. You are advocating people to spend man years of work just as their company start to get sucessfull porting their codebase, instead of stopping a couple of minutes earlier on to correctly decide what tools they'll need.
  - falcolas 12y ago
    > instead of stopping a couple of minutes earlier on to correctly decide what tools they'll need. Based on my previous experience, I'm advocating exactly that. The reasons are: 1) Bikeshedding - Everyone knows that N technology is better than M technology, even if nobody has real work experience with N 2) Starting with a new technology that people have only done side projects in costs significantly more time than just a few minutes. 2a) Nobody knows what those costs will be before hand 3) By the time you actually have to spend those "man years", committing resources those "man years" of effort won't negatively impact your ability to reach new customers. 3a) This work will not be required "just as their company start to get sucessfull", but at some point after that. 3b) You will most likely not have to do a full re-write all at once. Small refactorings of the actual pain points is how its typically done (there are plenty of examples of this in the marketplace today - Google, Facebook, Twitter) 4) Premature optimization, YAGNI, DRY, etc. all apply to your technology choice as much as they do your codebase.
    - JoeAltmaier 12y ago
      For some values of startup, this all makes sense. If you're trying to solve a hard computing problem (not a social problem) then you have to write your own code. Turns out open source rarely gets around to hardening their code. The you get to decide - jump aboard some community and try to help them get the code where you need it, or write your own. The community sounds nice, but the thrashing there can add more work than it's worth - tracking (incompatible) changes, arguing for your APIs and layering etc. Doubles the job at least. Then you write your own. Again time wasted but not how you think. With examples of working code and/or a good idea what you need, you write it and it works. But you spend the rest of your life defending your decision. Every new hire naievely says "you could just have used node.js!" And you try to walk them down the design points but its almost hopeless. I'm maybe a little depressed about this right now. My startup just got refinanced under the condition we use open source for everything, and write our app as a web app. Which of course is a pipe dream, since our app does hard things using carefully written low-level code, complex network strategies and heuristics hard-won from a thousand customer issues met and solved. But no! Chrome can do all that, for free! So I'm asked to quit being a not-invented-here drudge and jump on board. Anybody hiring?
      - falcolas 12y ago
        Ugh. Good luck with that... Maybe you can pull a "Breach" and only use Chrome as your, well, Chrome. http://breach.cc/ http://breach.cc/

falcolas 12y ago

> At scale this absolutely matters. So worry about it when you get to scale, not before. Most products and startups never reach the scale at which such basic technology choices matter; their time is better spent growing the company (adding user features, attracting new users, etc) than fighting with technology. MySQL was never designed to scale to the levels which Facebook and Google use them. And yet both companies are still using them today, even as the roles they use them in diminish as better technologies are brought to bear. Technology shortcomings can be worked around, so long as you're still in business.

marcosdumay 12y ago
> So worry about it when you get to scale, not before. You are advocating people to spend man years of work just as their company start to get sucessfull porting their codebase, instead of stopping a couple of minutes earlier on to correctly decide what tools they'll need.
- falcolas 12y ago
  > instead of stopping a couple of minutes earlier on to correctly decide what tools they'll need. Based on my previous experience, I'm advocating exactly that. The reasons are: 1) Bikeshedding - Everyone knows that N technology is better than M technology, even if nobody has real work experience with N 2) Starting with a new technology that people have only done side projects in costs significantly more time than just a few minutes. 2a) Nobody knows what those costs will be before hand 3) By the time you actually have to spend those "man years", committing resources those "man years" of effort won't negatively impact your ability to reach new customers. 3a) This work will not be required "just as their company start to get sucessfull", but at some point after that. 3b) You will most likely not have to do a full re-write all at once. Small refactorings of the actual pain points is how its typically done (there are plenty of examples of this in the marketplace today - Google, Facebook, Twitter) 4) Premature optimization, YAGNI, DRY, etc. all apply to your technology choice as much as they do your codebase.
  - JoeAltmaier 12y ago
    For some values of startup, this all makes sense. If you're trying to solve a hard computing problem (not a social problem) then you have to write your own code. Turns out open source rarely gets around to hardening their code. The you get to decide - jump aboard some community and try to help them get the code where you need it, or write your own. The community sounds nice, but the thrashing there can add more work than it's worth - tracking (incompatible) changes, arguing for your APIs and layering etc. Doubles the job at least. Then you write your own. Again time wasted but not how you think. With examples of working code and/or a good idea what you need, you write it and it works. But you spend the rest of your life defending your decision. Every new hire naievely says "you could just have used node.js!" And you try to walk them down the design points but its almost hopeless. I'm maybe a little depressed about this right now. My startup just got refinanced under the condition we use open source for everything, and write our app as a web app. Which of course is a pipe dream, since our app does hard things using carefully written low-level code, complex network strategies and heuristics hard-won from a thousand customer issues met and solved. But no! Chrome can do all that, for free! So I'm asked to quit being a not-invented-here drudge and jump on board. Anybody hiring?
    - falcolas 12y ago
      Ugh. Good luck with that... Maybe you can pull a "Breach" and only use Chrome as your, well, Chrome. http://breach.cc/ http://breach.cc/