"Failures are great learning tools -- but they must be kept to a minimum."
-Jeffrey Immelt

Failing: RethinkDB vs Mongo

RethinkDB started their quest in 2009, aiming to carefully build a better database that supported real-time data changes.

In 2009, MongoDB had just launched the first version of their product.

As RethinkDB came to market, they were compared to MongoDB. RethinkDB was clearly technologically superior. "Mongo doesn't even have 'atomic-ness' and its 'eventually consistent' how can you have a database that doesn't do the basic things that a database should do?" they thought derisively.

Using MongoDB, you may as well be printing your data on paper, tying it to a carrier pigeon, and instructing the pigeon to fly to a datacenter where someone is waiting to type in the data. I mean, it might work, eventually, but you're also going to lose some data and the data that you do get will sometimes be… let's say "messy"1.

In a retrospective after their eventually shuttering (spoiler), RethinkDB thought about one metric in particular that users cared about, he says:

"[Our competitor did this well] while we fought the losing battle of educating the market [of why it was a bad measure and why our product's outcomes were better]."2

Do you know anyone using RethinkDB? Didn't think so.

It was Beta vs VHS - the superior technology ultimately losing out.

There are, of course, a number of ways that a company can fail. How does one avoid the dustbin of history? Maybe there is a way to learn key lessons some other way, instead of learning the lessons too late3.

Finding Lessons4

In 2009, when RethinkDB was just getting started as a company, a different company, Fog Creek Software, was on the opposite US coast, already 10-years old and was looking at software companies and rethinking their own approach.

This is captured in an article5 then-CEO, Joel Spolsky, references different software wars: early databases, and word processing software (wait, you ask, there is anything other than Microsoft Word, Google Docs, and maybe Apple's Numbers6), as he gets reflective of his own profitably bootstrapped company but imagining a potential future demise indicates by a slow growth rate.

Spolsky is asking a business strategy question, not one specifically related technological process or advantage. But the parallel can be seen in Akhmechet's retrospective:

"[RethinkDB] optimized the product for the wrong metrics of goodness."7

We find Spolsky asking a similar question: "Are we that company that is thinking about the wrong things? Have we been optimizing for the wrong things?"

He compares his business to an unnamed competitor which seems to be Atlassian who makes Jira, Confluence, and also BitBucket. Have you heard of at least one of these? I thought so.

Meanwhile the truly awesome issue-tracking / project management product that is "Manuscript"8trucks along in relative obscurity as compared to Atlassian's Jira.

This unnamed competitor is driving sales which, in a world a sales-promised date meets software development, the wheels of the business can come flying off9. Whereas, for the past decade, he has strategically aimed at avoiding "half-baked jobs" and instead delivering quality: driving software quality or "goodness" of the software not speed of sales, growth rate.

But, in visiting his personal mental archives of decades of software businesses who have succeeded and failed, he has a somewhat existential crisis: might FogCreek be destined for slow failure due to this measured approach? What needs to change to avoid the potential failure?

He is trying to learn by listening instead of learning by failing10.

Cut back to Akhmechet's examination: "Could we have done anything to avoid these mistakes? … [No.] We were unconsciously incompetent, and it took years for that incompetence to become conscious."

That is, if it were something they were conscious of being incompetent at, they could solve for it. And they could learn from lessons instead of having to painfully, slowly, learn from failure. So the task is to become conscious to your own incompetence.

In Akhmechet's words, "Learn to recognize the talents you're missing, then work like hell to [solve for them]."

Learn from taking lessons from history instead of repeating the mistakes that have been done by others and only learning from your own failure.

Postscript

As the credits roll, it is 11 years after the RethinkDB's start and of Spolsky's analysis of their little company in NYC. In that time, Spolsky went on to start StackOverflow11 (the 45^th most trafficked on the internet-massively popular with programmers) and had a hand in starting the widely popular tasking/card-sorting product: Trello.12

Eventually Trello spun out as a separate company. After a few years, it was acquired… by Atlassian.

Links & Notes

1. Or, in Slava Akhmechet's words in his retrospective, "It was unfathomable to us why people would choose a system that barely does the thing it's supposed to do (store data), has a big kernel lock, throws away errors at random, implements single node features that stop working when you shard, has a barely working sharding system despite it being one of the core features of the product, provides essentially no correctness guarantees, and exposes a hodge-podge of interfaces that have no discernible consistency or unity of vision."
   https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html
2. Ibid. https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html
3. As a bonus, since failures tend to take longer than alternative methods of learning, one can learn potentially learn faster through paths other than failing and one's short life can only contain a limited number of attempts. This is especially if one is talking about the failure of a company, these lessons were for RethinkDB, 7 years.
   Learning faster is a net good.
4. I'd rather call this section "History" but that sounds somehow more pretentious. But an examination of history (whether our own or someone else's) is one of the fundamental ways to learn. Sometimes we abstract this examination into principles that are subsequently "taught" but the source remains the same.
5. Originally, https://www.inc.com/magazine/20091101/does-slow-growth-equal-slow-death.html; see also: https://www.joelonsoftware.com/2009/11/03/does-slow-growth-equal-slow-death/
   Early capture of the Inc magazine article text: http://web.archive.org/web/20100308042806/https://www.inc.com/magazine/20091101/does-slow-growth-equal-slow-death.html
6. Alright, there is also this Libreoffice thing that is probably still a project? I'm not even sure.
7. https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html
8. Manuscript started life as "FogBugz". The company has (or had) a wiki product as well (like Confluence) and also a hosted DVCS too (like BitBucket).
9. Timed well, perhaps only one wheel at a time, so you can keep going on three wheels while you scramble to replace the missing wheel with a better one before the next wheel comes off and you repeat the process again.
10. Spolsky's writing are filled with software history and analyzing strategic mis-steps always aiming at finding the paths for how to build a successful technology company.
11. StackOverflow represents another learning: despite years of worrying about the dangers of venture capital (Fog Creek was bootstrapped), Spolsky and Atwood took on venture capital to build StackOverflow.
12. What about the fate of our other characters?
    RethinkDB shutdown as a company, though it was trying to become an open source project in order for the technology to live on.
    Mongo DB? The company IPOed 4 years ago for unicorn valuation, less than a year after Akhmechet's retrospective blog post.