Marty is a smart guy. He was smarter than me when we were in college together, and he's smarter than me now.
But I disagree with him strongly here.
Sometimes hipster tech is just hipster for the sake of hipster, but if I have to choose between a sharded replicated MySQL cluster with some sort of active/passive across the WAN HA or Cassandra, I'm choosing Cassandra every time, and it's not close.
Why are you choosing Cassandra every time? And what's your refutation for his desire to use MySQL over some other database, from his point of view as presented in the article (e.g. availability of support via Google/SO)?
Linear horizontal scaling (double capacity? double # of nodes), no SPOF, Active/Active/Active cross-WAN HA.
> And what's your refutation for his desire to use MySQL over some other database, from his point of view as presented in the article (e.g. availability of support via Google/SO)?
Short of inherent big data problems, such as crawling the entire web, you won't need database scaling until you're already not a startup any more.
Cassandra and similar technologies constrain your queries and make schema changes incredibly expensive. This is the opposite of what you need in a startup. You need flexibility.
This article was about what stack to use for a startup and reddit is certainly no longer a startup. Tech stacks definitely change to adapt to its needs, at some point a company should be trying out cutting edge stuff. But the stack a 100 person company is capable of maintaining is very different than what a 3 person company can handle.
I think this is really great advice. This mindset was critical for me to finally start finishing up my side projects. For me, working by myself, 'Choose the tech I know best' is more applicable (although that generally happens to be the boring tech anyway.) But 'stick to the boring tech' is probably much better if you need to eventually start hiring employees. In my experience, technology stacks change drastically as a company gets bigger.
That said, as always, YMMV. Using cutting edge technology certainly has its place. There's just a learning and maintenance curve to account for that can often get in the way of releasing and running your MVP. But if you've taken that into account, it could be fine for your startup.
If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.
That said, quoting for example jdiscar (https://news.ycombinator.com/item?id=11804709), "'Choose the tech I know best'" is a better metric than "boring" per se. Circling back to Graham, perhaps you should defer doing a startup until you know enough "non-average" tech.
And I add this rule of thumb: adopt at most 1 new (big) technical thing. With everything else you'll be doing, you're not likely to be able to come up to speed on anything more.
And very possibly that one new thing is built into what you're doing, such as applying technology you know at a qualitatively greater scale than you're familiar with. I saw this a lot in the late '80s and '90s when PC architects familiar with single user systems tried to make the jump to multi-user client server systems.
Choosing and using tech is only one of the things a startup does. I would guess it's more important to do something odd for everything else than it is to do something "odd" tech-wise.
Perhaps that's an "it depends", and "odd" tech can enable you to do something "odd" that your competitors can't do. When I was skimming the cited article for the quote I plucked out of it, I came across this bit:
What were the results of this experiment [in using Lisp, which we knew, but didn't know anything else, like about business]? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.
While currently popular scripting languages can also give you fairly rapid new feature development times, their decision to use a language and ecosystem that allowed for lightening fast development (plus, let's admit, very smart programmers) allowed them to do something that every else was doing, web storefronts, but in an "odd" manner, with an OODA loop their competitors couldn't dream of touching (https://en.wikipedia.org/wiki/OODA_loop).
17 comments
[ 3.7 ms ] story [ 54.3 ms ] threadBut I disagree with him strongly here.
Sometimes hipster tech is just hipster for the sake of hipster, but if I have to choose between a sharded replicated MySQL cluster with some sort of active/passive across the WAN HA or Cassandra, I'm choosing Cassandra every time, and it's not close.
Only because you don't know what you're talking about.
Cassandra is awesome for log data that you don't care about. SoT data that you want to do range queries and be auditable? Not so much.
Linear horizontal scaling (double capacity? double # of nodes), no SPOF, Active/Active/Active cross-WAN HA.
> And what's your refutation for his desire to use MySQL over some other database, from his point of view as presented in the article (e.g. availability of support via Google/SO)?
Hire people that can learn DB internals and be the expert you want to see in the world: http://stackoverflow.com/search?q=user:4774369+[cassandra]
Cassandra and similar technologies constrain your queries and make schema changes incredibly expensive. This is the opposite of what you need in a startup. You need flexibility.
Would you argue in favour of MongoDB?
Never looked back after stared using it a few months ago.
That said, as always, YMMV. Using cutting edge technology certainly has its place. There's just a learning and maintenance curve to account for that can often get in the way of releasing and running your MVP. But if you've taken that into account, it could be fine for your startup.
[1] http://mcfunley.com/choose-boring-technology
If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.
That said, quoting for example jdiscar (https://news.ycombinator.com/item?id=11804709), "'Choose the tech I know best'" is a better metric than "boring" per se. Circling back to Graham, perhaps you should defer doing a startup until you know enough "non-average" tech.
And I add this rule of thumb: adopt at most 1 new (big) technical thing. With everything else you'll be doing, you're not likely to be able to come up to speed on anything more.
And very possibly that one new thing is built into what you're doing, such as applying technology you know at a qualitatively greater scale than you're familiar with. I saw this a lot in the late '80s and '90s when PC architects familiar with single user systems tried to make the jump to multi-user client server systems.
Choosing and using tech is only one of the things a startup does. I would guess it's more important to do something odd for everything else than it is to do something "odd" tech-wise.
What were the results of this experiment [in using Lisp, which we knew, but didn't know anything else, like about business]? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.
While currently popular scripting languages can also give you fairly rapid new feature development times, their decision to use a language and ecosystem that allowed for lightening fast development (plus, let's admit, very smart programmers) allowed them to do something that every else was doing, web storefronts, but in an "odd" manner, with an OODA loop their competitors couldn't dream of touching (https://en.wikipedia.org/wiki/OODA_loop).