DHH (of Basecamp and Ruby on Rails fame) said something on Tim Ferriss’s podcast last year that stuck with me:
Finally, I’d say we employ the same tactic that we encourage everyone at the company to employ, which is to stop talking and start making. When we have disagreements about which way to go, just trying it usually resolves things very quickly. So if it’s about a feature in Basecamp, then you have to implement it and see how it feels and see how it works.
If it’s about a marketing strategy, just find the smallest way you can get a disprovable test going and then try it. And if I think something is not going to work and we try it and it doesn’t work, okay, so what? We wasted a little bit of time? We wasted a little bit of money? No big deal. If we can try something I don’t think is going to work and it works? Again I win. So if you look at it from that perspective, you can “win.” You can get to the great outcome in all cases.
Whether you’re right or whether you’re wrong, you still win. If you’re right, then we’ll carry on with that idea. If you’re wrong, then hey, that great idea made it through even with your position.
David Heinemeier Hansson
This idea both haunts and motivates me in software development. We spend so much of our time talking about the right architecture, the right framework, the right tooling, the right whatever. And we can’t ever know that whatever choice we end up with is the best one, if all we’ve done is talked about it.
Say we talk for awhile and decide on a solution. Maybe it works OK and we roll with it. We’ll never know if the better solution is the one we talked ourselves out of, which we would have recognized if we had tried that one too.
“The Lean Startup” is a great book based on this idea. Its argument (as stolen from the Wikipedia page) is:
Building an MVP (Minimum Viable Product) and then testing and iterating quickly results in less waste and a better product market fit.
The book is for startups (obviously) but the principles can work for lots of different technical decisions.
A brief example
Here’s one from experience. I spent a solid 2 hours in a meeting talking about a Drupal module that adds some automation about configuration export and import. We discussed the pros and cons, how much time it could save, if it was dangerous to automate, if it was built well, on and on and on. By the end, we didn’t settle anything.
Then, someone tried the module and pointed out that it’s buggy in weird ways and it makes saving config forms slower (which is a problem in Drupal site building, because you’re saving a lot of config forms). And that was that. It was a definite no. We could have thrown away the 2 hour meeting if someone had spent 5 minutes trying it out.
But this all takes time, gah!
Yeah, trying stuff out that you may not use takes time. It may take more time than you would have spent debating it. But that doesn’t matter since it gives you confidence in your decisions that you can’t get from talking.
It doesn’t have to be that painful. We’re spoiled these days with Docker, and lots of things can be tested in a disposable local environment after a couple commands. I’m trying to make an effort to use that. When a debate just keeps on going, I’ve been trying to find a spot to say “let me just try it and report back” and that ends it pretty quickly.
If trying something out in a throwaway environment takes a lot of setup time, then fix that. That’s a problem. Throwaway environments are valuable, and valuable things should be easy. If they aren’t, then fix that problem.
So minimize the time that it takes, and accept that what’s left is necessary and valuable and worth it. Like DHH said:
We wasted a little bit of time? We wasted a little bit of money? No big deal. Whether you’re right or whether you’re wrong, you still win.”
David Heinemeier Hansson
Mike Crittenden 