Ben Kamens is the lead dev of Khan Academy, the incredible free resource for education, recently explained “shipping beats perfection”, one of the organization’s development principles. It’s good reading, plus has pictures of a smiling dog, so you should go read it.
From their principles page:
Scope features down to their core before getting started. Iterate outside of the code. Use mockups, design discussions, and anything else that helps you cut out the nonessential before diving into the 1s and 0s.
Sounds like Agile software development to me. You don’t code immediately after being told what features are needed. You find out what actually provides value. You learn how the feature will be used, which will inform the algorithms and design. You find out what isn’t needed. You’re more likely to deliver the right feature.
But Ben found more explanation is needed. Too many people hear “shipping beats perfection” and think “we ship poor quality.”
He boils it down to three phrases:
We’re willing to be embarrassed about what we haven’t done…
If there’s something missing, that’s temporary. Well, frankly, everything is temporary, but if something is missing, it can be rectified by creating it.
And creating it should only be a decision made if it turns out that there is a demand for it. Energy and effort aren’t expended on guesses at what provides value.
You could try to build everything at once, but more and more, people are realizing that it isn’t necessary. The Lean Startup by Eric Ries is the latest hotness that argues for building a minimum viable product. When you have something out in public, you can learn what the public wants, change your approach to meet the need, and constantly learn and improve.
In a way, you’re throwing spaghetti at the wall. You have something you’re making, but you don’t know how it should feel or look until you get some feedback.
…but not willing to be embarrassed about what we have done.
Whatever is shipped is high quality. It’s not counterintuitive at all. Quality is about what the customer receives. If you don’t build quality in from the beginning, you’re building your product on quicksand, and future work becomes a slog through past poor decisions.
Leave it better
It’s the idea that you never leave an area of code without doing something to improve it.
I’ve written in the past about how you’re responsible for your code. The quality of your code is a result of past decisions. Sometimes hacks are needed to get value out earlier, but eventually you have to pay down the tech debt if you don’t want it to slow you down later.
But how do you know when you’re over-engineering versus purposefully writing tech debt versus hacking?
What’s key is who is being served by your efforts.
If you are embarrassed by code you wrote, you hacked. You and your fellow developers weren’t served by it when you have to return to it later.
If you are embarrassed by what code you needed to change to, then it’s probably tech debt you haven’t gotten to yet.
If you seek out perfection in engineering, however, you have lost sight of the customer.
That last one describes my efforts in creating Stop That Hero!.
A couple of years ago, I wrote about the importance of speed. Getting games to market more quickly, getting feedback from players more quickly, finding the fun as quickly as possible were all things I was failing at. I wrote about how my development was much slower than I would have liked, and I got a lot of advice from commenters.
What a lot of it boiled down to was that my goals weren’t clear. If I was aiming to learn how to write code and how to build things from scratch, I was doing really well. I was practicing test-driven development. I was learning about artificial intelligence. I was even learning how to use the Gimp to create decent programmer art. I was building up discipline, skill, and knowledge.
If, however, I wanted to make an entertaining game for paying customers in order to make a living, I wasn’t doing a good job of focusing on value delivery. The biggest problem was that I didn’t know exactly who my customers would be.
So who determines what quality work really is?
As Michael Gerber explains in One Game a Month site. Are they perfect games? No. Are they commercially competitive? Hardly. But I am proud of what I was able to get out there, and it’s gratifying to hear feedback from actual players.
Khan Academy has internalized this idea of finishing and delivering value as a key principle: “shipping beats perfection”. I need to remember to internalize it myself.
