The best tool for the job, isn’t always
Or — why we cruelly force our developers to use Backbone.js
Note: This blog post was written while I was still employed as Lead Front-end Engineer at Disqus. I’ve since started a new gig, but everything here still holds.
It’s been said a million times: when you’re starting a software project, choose the best tool for the job.
If you’re writing a multi-threaded application, you should probably use Go, or Erlang, or Clojure, or another language designed for parallelism.
If you’re working with schema-less data, you should probably use a key-value store like Redis, or Riak — not a relational database.
If you’re writing a full-featured single-page JavaScript application, you should probably use Angular, or Ember, or something similar.
At least, that’s how you should evaluate these decisions if you’re operating in a silo. But most of us aren’t. When you’re a part of a team, or an organization, you’re no longer choosing for you — you’re choosing for everyone. With that responsibility, technology decisions aren’t always so cut and dry.
Tyranny
At Disqus, in the past year, we recently standardized on a set of technologies organization-wide:
Backbone for client-side apps. Django for server-side applications. (With exceptions, of course.)
Are you writing a complex single-page application, and feel that it’s the perfect place for Angular — which you’ve toyed around with in your spare time?
Sorry — use Backbone.
Are you writing a small web service for processing payments, and feel that Flask — a micro web framework — would be a better choice?
Sorry — use Django.
This is, of course, a simplification. But you get the idea.
The greater good
I’m a developer. And a darn good one too. How do you know that these are the best tools for my needs? — Straw man
We don’t. And they probably aren’t — in isolation.
We standardized on these technologies for the benefit of the organization at large. Not any individual project.
While Angular might seem like a great fit for your single-page application, and by all accounts a sweet piece of technology that many people love, there are other factors at play.
Like — does anybody here actually know Angular? Is someone going to be available, and capable, of reviewing your code?
Have you built a non-trivial app before in Angular? Will your “I’m learning as I go” attempt result in a maintainable piece of software?
If you get bored and quit in a year, will someone be able to pick up your code and get running? Or will they give up and just re-write it in tomorrow’s popular framework?
Will you be able to use the tools we’ve already developed on top of Backbone?
Benefits of the ecosystem
At Disqus, we’ve been using Backbone since late 2011. We’ve built a lot of things with it. Our embedded commenting widget, for example. Our new user dashboard available at disqus.com. And a handful of internal applications.
By using Backbone organization-wide, we’ve gained some things.
We have 8 full-time front-end engineers that are experienced writing Backbone apps. We know the patterns. We’re familiar with the internals. We can move between projects, and we can help get new projects started fast.
We’ve built tools on top of Backbone. Models and collections that communicate with our web service API. Utilities for listening to our realtime service. Views and templates that can be re-purposed into different projects. They’re documented; they work; they’re proven.
So while newer frameworks like AngularJS might present legitimate productivity gains, those gains shrink fast when you consider that a wealth of tools built for our ecosystem may need to be re-written (and maintained) to support it.
My fear in writing this blog post, is that people will read this and think “What, I can only use Backbone at Disqus? Eff that.” That people will think we’re dinosaurs (Backbone came out in 2010 after all). That it will kibosh our recruiting opportunities.
I hope not. I hope that people recognize that in a growing company, one-off applications written in someone’s pet languge can cost more than they’re worth. That investing long-term in a tool chain provides serious productivity benefits. That writing quality, sustainable software comes second to fiddling with what’s sexy.
And for what it’s worth, we still work with dozens of “progressive” software languages and tools. For example, we’ve been using the edge version of Phabricator since it spun off from Facebook in 2011. We’ve built an automated translations process in NodeJS that supports 100+ languages. We deploy on bleeding-edge CDNs, have production code in Go and Scala, and use buzz-wordy front-end things like WebSockets, CSP, and CORS.
And one day we’ll move on from Backbone. And maybe even Django. But when we do, it’ll be because the benefits of the new framework/library outweigh the costs of staying with the current solution. When the organization benefits — not just the individual.
You know — when it makes sense.
I don’t work at Disqus anymore, but they’re a great bunch of folks trying to solve some very difficult problems around online discussions.
If you’re interested in working at incredible scale on a small-ish team, I strongly recommend dropping by their jobs page.
