Sometimes the best solution to a problem is to step around it.
When was the last time you butted your head against a technical challenge and had several failed attempts to solve it? Maybe it was due to limitations of the platform you’re using or limitations of your own technical ability. Or maybe it was just a really freakin’ hard problem to solve that is solvable via technical means but not ultimately worth the energy for doing so.
Sometimes the best solution isn’t to “beat the problem” so much as to side-step it with a human-powered solution. I’m going to show you a technique for doing this called “Flintstoning” and give you some guidelines for how to identify situations where a low-tech Flintstoned solution might make more sense than tackling the problem head-on.
What is Flintstoning?
Flintstoning is using human power under the hood to solve what would traditionally be a software-based problem. I first heard this term back in 2006 via Cambrian House. It’s typically used in the context of doing things in a decidedly-manual way early on in a startup for the sake of learning a process inside & out before you try to automate it. But it’s valuable in other contexts such as in the case where you have a particularly elusive technical challenge that meets a certain set of criteria.
When does it make sense to Flintstone?
If you can answer yes to these five questions it’s likely that your problem is a good candidate for a Flintstoning-based solution:
- problem is particularly “fuzzy”
- a human can do the task cheaply
- easy to expose an interface
- costs of solving via software-powered outweigh value of problem
- does not need to be solved in real-time
Let me give you a concrete example of a good Flintstoning solution candidate from a comment on one of my recent YouTube videos:
This guy Tapan is asking if it would be possible to use my hack with browser-based automation for essentially doing periodic garbage collection clearing out unused photos in his database after a certain time period.
Browser-automation really isn’t the right tool for this. He needs the equivalent of a cron process that runs in Adalo and handles this but Adalo currently has no concept of time-based system generated tasks so he’s scratching his head trying to figure out how to automate this garbage collection process.
Rather than engineering a technical solution I suggested he just hire a virtual assistant (VA) to log into his app weekly and clean out the unused images in the database. Given how Adalo works with the ability for two apps to share the same database it’s trivial for him to create a special admin interface for his VA with heavily-restricted permissions that enables that person to handle this without creating any real security risk. With maybe two hours of work between recruiting and tasking the VA and writing a quick visual interface his garbage collection problem is solved with no more head butting. He’ll pay a few dollars each week in VA fees but has saved would could be a couple thousand dollars in dev work and has the problem handled immediately so it’s a massive win.
Considerations and tools
Obviously not every problem lends itself to being solved in this way but by going through your feature backlog and analyzing what’s on your plate dev-wise using the above five questions, you may find you can knock out a bunch of features using this technique in short order.
I have a few VA’s from Upwork on retainer in Slack with standing open hourly contracts and for situations like this I can simply record a Loom video and task them in situations like these. This works well for situations when there’s a bit of context required to understand and complete the task and it’s low-priority and infrequent work that’s required.
For situations where the work is more mindless, 24/7 and needs to scale beyond what one person can handle Amazon offers a service called Mechanical Turk to programmatically task humans with small jobs called HITs (human intelligence tasks). It’s basically like a realtime eBay of grunt work in which you’re farming out this labor via microtransactions of a few pennies from within your app. That’s a topic for another post but a powerful tool to have in your arsenal.
Conclusion
Next time you find yourself going down a rabbit hole of failed technical attempts at solving a problem, use the questions above to determine whether your problem is a good candidate for a Flntstone solution. It’s a win all around with you getting a cheaper/faster/resilient solution in place while also employing someone who is happy to have the work.
In a future post I’ll deconstruct the two main underlying principles of this technique of Flintstoning which are two design patterns I use called “Inversion of Control” and “Airlocks.” I’ll show you how those are like lego blocks that can be used in conjunction with a third I call the “Horserace” pattern to solve hard problems creatively. Be sure to join my email list if you want exclusive content like this around automation, leverage and lateral thinking in your inbox. cheers
UPDATE 6/10/20: This post got some traction on Hacker News yesterday and a few people pointed out in the comments that there is already another name coined for this technique: The Wizard of Oz Paradigm. Name it whatever you like. The important takeaway is that this technique of software-invoked human intervention is a powerful fudge factor to use in your apps that can give you a superpower for solving a class of problems that would otherwise require unjustifiable time & dev resources to solve.
