The tagline for Amazon Mechanical Turk is “Artificial Artificial Intelligence”. As in, faking your AI by using humans. Mechanical Turk is named after the contraption in the title image, which was a seeming chess-playing automaton from the late 1700s that was secretly operated by a small human hidden inside.
But this post isn’t about Amazon’s nifty service or sham futuristic exhibits. What is it about? I really just want to coin a cute term for a principle of startups. There are a lot of related ideas floating around already, like premature optimization being the root of all evil. Or Y Combinator’s admonition to do things that don’t scale. In that essay, Paul Graham includes the following:
Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users’ problems in a way that wasn’t yet automatic, but less frightening than the far more common case of having something automatic that doesn’t yet solve anyone’s problems.
Generalizing that slightly, here’s what I call the Shirk & Turk Principle: When writing any new app or website or feature, implement as little of it as you can get away with and manually fake the rest behind the scenes. Don’t write code in anticipation of its usefulness, write code when you have to.
“When writing a new app or website or feature, implement as little of it as you can get away with and manually fake the rest behind the scenes”
Why is that a good idea? Because it’s amazing how often you implement the wrong thing or users fail to use it for whatever reason. “If you build it they will come” is up there with “you can parse HTML with regular expressions” as a Great Falsehood of Software Development. So apply another computer science principle — the principle of delayed commitment [1] — and don’t waste time building something until you know for certain you need to. How do you know? Simply when you can’t keep up with doing it manually, because enough people are actually using the shell of a thing you built.
Let me drive this point home with some stories.
Beeminder started life as Kibotzer, the kibitzing bot. The bot would email [2] you asking for your number (e.g., your weight) and would send you back a graph of your progress. Guess who the bot was at first? In that case I wasn’t exactly turking, since I wasn’t pretending there was any automation.
Stripe started life as “/dev/payments” with the idea that you should be able to treat payments like a Unix device file (so delightfully nerdy!) where there’s a bunch of real-world complexity that is elegantly abstracted away for you. You should be able to send money around as easily as piping the contents of a file. Beeminder is proud to be one of the first users of what is now Stripe and the founders later let us in on the secret that they were manually faxing documents around behind the scenes on our behalf to give us the experience of signing up and having money magically start appearing in our account when users paid us.
Another Beeminder example: When Beeminder is about to charge you money for going off track on your goal, we (automatically) send an email asking if there was any technicality or confusion or anything that would render the derailment not legit. The user can reply to the email to say whether it was or not. Our original intention was to automate that process in some way but we figured we’d start with shirking & turking it. We’d just manually read the replies and cancel charges as necessary.
But funny thing about that example, the human interaction has proved critical in keeping people honest. Sometimes new users presume the process is automated and reply with a bland “not legit”. We reply with something like “oh no! what happened?” and they quickly realize they’re dealing with an actual human. We’re pretty sure those actual humans will always be part of the service Beeminder provides.
So that’s the extreme case of it being wisest not to write code too soon — we turned out to never want any code at all for that feature.
This is a hard lesson for computer nerds like me to learn. Even when you know there’s one single user — yourself — you may delude yourself into thinking it’s still worth writing code.
And sometimes it really is (or the coding is its own reward). But that comic is funny because of how often it’s true. And with users other than yourself it only gets worse.
In conclusion, let me repeat all that in an overly rhymey haiku:
Specs and reqs are murk,
Also writing code is work.
Simply shirk & turk!
UPDATE: Related concepts include Wizard of Oz MVPs and Concierge MVPs. (MVP being the startup term for Minimum Viable Product — the idea that you should ship things as early as possible, arguably as soon as you have something that provides any iota of utility to even one user. Or at least ask yourself pointedly, if the product doesn’t have feature X, is it better that the product not exist at all? Only if feature X really is that fundamental should X be part of the MVP.)
UPDATE: See also “Manual Until It Hurts” from our old friends at IndieWebCamp.
Footnotes
[1] Or principle of least commitment in AI circles. It’s the simple decision-theoretic fact that you shouldn’t commit to a course of action until you have to. Flexibility is valuable; laziness is a virtue. It’s also one of the Lean Software Development principles. And I’m sure it comes up in other fields as well.
[2] Related idea: Email-First Startups. Instead of building a product that’s web-first or mobile-first or tablet-first, think about whether you can get away with building one that’s email-first. Like where the entire interface is via email. This also makes it especially easy to apply the Shirk & Turk Principle!