On choosing boring technologies
A reaction / agreement to Choose Boring Technology
I remember a very early argument at Bloc that I’m sure Roshan will remember. It had to do with whether or not we should build our application in Ruby on Rails or some combination of separate frontend and backend tech.
Those of you who know me now, 6 years later, may be surprised that I was an advocate of the separate frontend and backend approach. I can’t quite recall what argument I made, but I bet it was some combination of “this is the standard approach”, “this will scale”, “this is how everyone else does it”, and “you’ve gotta choose the best tool for the job”.
I believe, without a doubt, I was 100% wrong. Roshan was right. Roshan, you were right!
My approach would’ve meant we moved slower. We would’ve spent more time thinking about our technology choice rather than our customer problems. And it turns out, we didn’t need to scale to millions of users because our business didn’t require it.
Velocity is everything. It’s everything. Especially at an early stage startup where you haven’t achieved product market fit.
Now I’m not saying you should never try new technologies. You should. But you’ve got to be explicit about what you’re optimizing for. If you’re optimizing for velocity, then you better be able to explain how that technology choice is the best approach for velocity. If you’re optimizing for something else, that’s fine, but be explicit about it, and about how it ultimately maps to your ability to move faster to solve your customer’s problems.
If you find yourself solving a rather standard problem (building a messaging system, forum software, any flavor of CRUD, authentication system, etc) and you choose the “latest and greatest” without explaining how that is going to make you faster, I believe you’re making the wrong choice.
I’m a bit surprised at how divisive this stance has become. I’m not even advocating any particular approach or tool or framework – just being explicit about why you’re choosing it and being honest with yourself about whether or not velocity is the thing you’re optimizing for. If your team is full of top notch javascript engineers who know node.js inside and out, great, that could totally be the right choice.
For me, that choice is Ruby on Rails. The amount of velocity I can squeeze out of this framework after the better part of a decade working in it is insane. I sometimes forget this, and then I dip my toes into the waters of another stack and am reminded of the fact. It’s not that these other stacks are bad, or that I dislike them, or that I think they made terrible technical choices. It’s that I’m an order of magnitude slower when I use them.