Mongo: Mr. Right... or Mr. Right Now?
I've spent the last 6 months building Scripted with deliberate recklessness. Not a single one of the features I've pushed was ready, tested or beautiful. My mantra was "Push first, ask questions later". A couple of factors made this possible.
For starters, I'm the only engineer. So I'm never held accountable for my code (no one else can read it), and I know how everything works. I push with moderate confidence knowing that new features won't break old ones.
Secondly, we have an incredibly engaged writer community. Which means that every time something breaks I get an email about it immediately. Who needs Airbrake when you've got 15 insomniac writers with your personal email address?
That second part isn't changing; our writer engagement stats are only going up! But the first part is. I just hired my friend, and the yin to my programming yang, Sylvain. All of a sudden we're no longer a one-man Rodeo-show, we're building an engineering culture. In just two days he's helped me set up a system for one-step deploys, a testing suite (god forbid!), and monitoring services for server and code health. Then we got to talking about the design and infrastructure decisions I've made.
I maintain that MongoDB is the right database for us. Our data is basically a bunch of big blobs of words and very unstructured reviews of those words, which seems perfect for a schema-less document store. But some day we might decide that Mongo wasn't the right choice. I think one of the biggest mistakes a company can make is being distracted by sunk cost, so I try to keep an open mind to the possibility of architectural refactoring. Regardless of whether we live on Mongo forever, I am confident that it was the right choice for the past six months because I didn't have to write a single migration.
I think this is often overlooked. I see two distinct stages to product development. There is the initial push where all that matters is speed. This is the stage to which Max Levchin is referring when he argues that "Speed is your only weapon. All you have is speed". The diversity part of his argument is questionable (morally, legally and logically), but I think he is spot on when he explains that "Striving for optimality early on--debating pros and cons of various design decisions in intricate detail--would have doomed PayPal". Applying this to a database decision: architecting tables and writing migrations would have added weeks (if not months) to my development process. Instead, I used Mongo as a sort of speccing tool, renaming attributes, reconstructing associations and refactoring models willy-nilly with little concern for existing data on production. As I explained earlier, this Wild-West mentality works great when you're a solo-hacker. But now we are entering the second stage of product development: we've found a market niche, we've established a sales process, and our product works. Before all that mattered was speed. Now what matters is process and scalability. The jury is still out concerning how Mongo will scale given our particular application, but I can sleep sound knowing that porting our app to PostgreSQL wouldn't take us more than a week or two, but if I'd started with SQL I'd probably still be pulling my hair out over some botched migration.
For starters, I'm the only engineer. So I'm never held accountable for my code (no one else can read it), and I know how everything works. I push with moderate confidence knowing that new features won't break old ones.
Secondly, we have an incredibly engaged writer community. Which means that every time something breaks I get an email about it immediately. Who needs Airbrake when you've got 15 insomniac writers with your personal email address?
That second part isn't changing; our writer engagement stats are only going up! But the first part is. I just hired my friend, and the yin to my programming yang, Sylvain. All of a sudden we're no longer a one-man Rodeo-show, we're building an engineering culture. In just two days he's helped me set up a system for one-step deploys, a testing suite (god forbid!), and monitoring services for server and code health. Then we got to talking about the design and infrastructure decisions I've made.
I maintain that MongoDB is the right database for us. Our data is basically a bunch of big blobs of words and very unstructured reviews of those words, which seems perfect for a schema-less document store. But some day we might decide that Mongo wasn't the right choice. I think one of the biggest mistakes a company can make is being distracted by sunk cost, so I try to keep an open mind to the possibility of architectural refactoring. Regardless of whether we live on Mongo forever, I am confident that it was the right choice for the past six months because I didn't have to write a single migration.
I think this is often overlooked. I see two distinct stages to product development. There is the initial push where all that matters is speed. This is the stage to which Max Levchin is referring when he argues that "Speed is your only weapon. All you have is speed". The diversity part of his argument is questionable (morally, legally and logically), but I think he is spot on when he explains that "Striving for optimality early on--debating pros and cons of various design decisions in intricate detail--would have doomed PayPal". Applying this to a database decision: architecting tables and writing migrations would have added weeks (if not months) to my development process. Instead, I used Mongo as a sort of speccing tool, renaming attributes, reconstructing associations and refactoring models willy-nilly with little concern for existing data on production. As I explained earlier, this Wild-West mentality works great when you're a solo-hacker. But now we are entering the second stage of product development: we've found a market niche, we've established a sales process, and our product works. Before all that mattered was speed. Now what matters is process and scalability. The jury is still out concerning how Mongo will scale given our particular application, but I can sleep sound knowing that porting our app to PostgreSQL wouldn't take us more than a week or two, but if I'd started with SQL I'd probably still be pulling my hair out over some botched migration.
Subscribe for the latest in Content Marketing & Freelance Writing!
While you're here, have you tried Scripted lately?
Used to be a member, but moved on? Heard of it, but never signed up? The current iteration of Scripted will amaze you! Streamline your content writing efforts and build your own team of high-quality writers. It's all you need for content writing. Try it free today and meet your next favorite writer or writers!