3 ms·

This might be good advice if you're building cookie cutter systems for clients that have high turnover of contractors, but for startups I think it's horrible.

This might be good advice if you're building cookie cutter systems for clients that have high turnover of contractors, but for startups I think it's horrible. I'd take one person that really groks devops and database internals well enough to make informed choices over a million one-size-fits-all SQL/Mongo+MVC devs. Any day of the week.

pbiggar 12y ago
What do you do when that guy quits?
bdcravens 12y ago
but for startups I think it's horrible. Why? Wouldn't it make more sense for startups to color within the lines, in terms of getting features to market faster? I'd take one person that really groks devops and database internals well enough to make informed choices Funded or not, a startup has the responsibility to turn every dollar into a feature that creates revenue, not architecture.
- christiansmith 12y ago
  First, I never said "don't use SQL, even where it makes sense." The original commenter wrote, "advice to anyone deciding on a database". I strongly disagree with the notion that any practicing or aspiring creator should refuse to learn about and consider the full range of tools at their disposal, simply because there's a popular default choice. Specialized tools provide a form of leverage to those who understand and employ them wisely. Every problem I have ever come across that is sufficiently difficult and interesting to warrant forming a startup requires deeper insight on a technical level than "just ignore everything else and use X". Can you imagine if the founders of Google took this kind of advice?
  - deleted 12y ago
    [deleted]
  - bdcravens 12y ago
    Can you imagine if the founders of Google took this kind of advice? As a couple of examples, Google started on clusters of relatively commodity hardware. For years, AdWords ran on MySQL. Google's advantage wasn't in the innovative architecture, but rather, in the PageRank logic, which led to leadership in other areas. The architecture supports the innovation, which is the competitive advantage; the architecture isn't the competitive advantage.

pbiggar 12y ago

What do you do when that guy quits?

bdcravens 12y ago

but for startups I think it's horrible. Why? Wouldn't it make more sense for startups to color within the lines, in terms of getting features to market faster? I'd take one person that really groks devops and database internals well enough to make informed choices Funded or not, a startup has the responsibility to turn every dollar into a feature that creates revenue, not architecture.

christiansmith 12y ago
First, I never said "don't use SQL, even where it makes sense." The original commenter wrote, "advice to anyone deciding on a database". I strongly disagree with the notion that any practicing or aspiring creator should refuse to learn about and consider the full range of tools at their disposal, simply because there's a popular default choice. Specialized tools provide a form of leverage to those who understand and employ them wisely. Every problem I have ever come across that is sufficiently difficult and interesting to warrant forming a startup requires deeper insight on a technical level than "just ignore everything else and use X". Can you imagine if the founders of Google took this kind of advice?
- deleted 12y ago
  [deleted]
- bdcravens 12y ago
  Can you imagine if the founders of Google took this kind of advice? As a couple of examples, Google started on clusters of relatively commodity hardware. For years, AdWords ran on MySQL. Google's advantage wasn't in the innovative architecture, but rather, in the PageRank logic, which led to leadership in other areas. The architecture supports the innovation, which is the competitive advantage; the architecture isn't the competitive advantage.