Making stuff good is rewarding, making stuff great is intoxicating. It’s like there’s a direct line from perfection and excellence to the dopamine release. And the reverse is true as well. When you make crappy stuff, you feel crappy. No one likes to work in a broken shop on a broken stool.
So it’s hard to fault people from being attracted to sayings like “Quality is Free”. It validates the good feelings that flow from making stuff perfect, and it makes it seem like it’s a completely free bargain. Win-win and all that.
But like anything, it’s easy to take too far. Almost everything outside of life-critical software has diminishing returns when it comes to quality. Fixing every last bug, eradicating every last edge case, and dealing with every performance dragon means not spending that time on making new things.
You can make the best, most polished, least-defective saddle out there, but if the market has moved on from horses to cars for general transportation, it’s not going to save your business. And it doesn’t even have to be as dramatic as that. Making the best drum brakes is equally folly once disc brakes are on the market.
So you have to weigh the value of continuing to hone and perfect the existing with pursuing the new and the novel. This often happens in waves. You come up with a new idea, and a crappy first implementation. You then spend a couple of rounds polishing off the crap until the new idea is no longer new and crappy, but known and solid. Then it’s time to look hard at whether another round is worth it.
The bottom-line is to make that which is not good enough, good enough, and then skate to where the puck is going to be next.
seth godin
on 14 May 14“Quality is Free” is not merely a saying. It’s a book, by Phil Crosby.
http://www.amazon.com/Quality-Is-Free-Making-Certain/dp/0451625854
It’s totally worth reading, certainly before dismissing his carefully constructed and easily tested argument.
The kind of quality Crosby is writing about is indeed free. It’s the quality that comes from meeting spec, and it’s the quality that’s built in via processes and implemented by people who have signed up for a job in execution, not in invention.
The reason that it’s free is that it’s cheaper to do it write than to fix it later.
Jason
on 14 May 14Cool. But when you make business software that thousands and thousands of people rely on to get their work done every day, this philosophy leaves your customers struggling with (and paying for) your unsupported, “good enough” products.
Michel
on 14 May 14The way I like to approach this problem is to change my definition of quality to the best product I can build before wasting time on improvements that don’t really matter. Then building a product of the highest quality doesn’t mean it’s perfect, just that it’s exactly good enough for its intended use.
DHH
on 14 May 14Jason, you can apply this thinking within products as well. We’re committed to being all Basecamp now. But that doesn’t mean we have to keep polishing the very same ideal of what Basecamp was when we first conceived it.
That’s the transition we went through with Classic. But we also gave customers the best of both worlds: You get to keep using Classic if you want, and new people can get our latest ideas on what Basecamp should be.
But it applies on an even smaller scale too: New features vs Polishing existing.
You have to deal with this trade-off in every aspect of the business, but it’s better when you do it explicitly.
Andrew Starks
on 15 May 14There is an valuation process here. We decide, “is this worth it”, where it can be: “generalizing”, “making faster”, “parting out into its own service.”
So we cleverly place some kind of value and decide “if it’s worth it.”
As an example, consider your build process. Is it worth it on this one release to improve it? No. Will there ever be a release where it is worth it? No. If you amortize the value of an improvement over its expected life? Yes! And it will bring you happiness.
Build processes are an interesting example, because we have an elevated understanding of that domain, being developers. That level of understanding plays an important role in the narrative that you’re laying down.
If you understand your domain problem extremely well, then the risk of building software assets is lower. You can identify the simplest components of your domain and have a good shot at getting the contracts and separations correct.
So, should you spend the time to turn a particular sub-domain of your software into its own autonomous service, even though the next release does not warrant the effort?
The answer is not as simple as no, if:I don’t wish to needlessly nitpick a valid and important point. However, “don’t over build” and “release early and often” are the two messages that every developer gets hammered into them. There is a time and a place for research and architecture.
Like everything in software and in life, it’s all a balance.
I always enjoy your posts and thank you for this one!
-Andrew
Popernikoff
on 15 May 14< blockquote>The bottom-line is to make that which is not good enough, good enough, and then skate to where the puck is going to be next.
Totally agree! Make a “product” that’s “good enough”. Hype it. Sign up the suckers. Profit and “skate” on. There’s one born every minute.
Not.
Steve
on 15 May 14The real art here is knowing when “good enough” is “good enough”. With anything in life this is the case. Nothing will ever be perfect.
For example, if you are washing your car, you can spend 10 minutes washing it, or 5 hours. In the end, the car will never be perfectly clean, but I would say after about 30 minutes to an hour your car looks pretty darn nice and is fully capable of you picking up a hot girl/guy with it.
I am not in love with the word “good enough”. I think it is mostly associated with people putting in a half-A effort. If you look at anything that David is associated with (Basecamp, Rails, writing), I don’t see a half-A effort.
Having a negative connotation associated with “good enough” is seen in Popernikoff’s response. He is insinuating that the product is crappy and that those that sign up for it are suckers. However, a “good enough” product can be a great product (such as basecamp).
At one point in an product cycle, you have to ship the dang thing. The first iPhone wasn’t perfect, but it eventually became “good enough” for the first release and was a success.
This discussion is closed.