One of the topics that frequently gets discussed in engineering circles (or maybe I should say product circles) is the concept of when to release. I say product circles because engineers I am convinced would be happy to keep a project in continuous improvement forever. It’s in our blood. We have this innate desire to continue to make something better and every time we look at a project we’ve found a half dozen ways we can continue to improve it before we call it a product and release.
This is a blog for everyone though, not just engineers so let me take the back a level and make it more of a general concept discussion.
The perpetual debate that happens in any company who releases software or ships a product is about when to ship and when to perfect. And there are a million different pieces of advice and ways to look at the situation. Apparently, based on the majority of those, most people tend to hold on to things too long and never ship. As a result the most common advice is to Release early, release often and iterate. Great companies have pushed this mantra in the past and possibly one of the most well-known of the modern era, says this:
Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.
“Done is better than perfect” and “Move Fast and Break Things” are two of the common phrases associated with the Facebook movement. Both of these focus on this same sentiment. Speed and early releasing is more important than waiting for perfection.
I understand the mentality. I agree with the sentiment. And I encourage others at Mautic and in the community to think this way as well. There’s truth in saying that “we must quiet our fearful ‘lizard brains’ to avoid sabotaging projects just before we finally finish them”. But, it’s also important to not release prematurely. While this caution doesn’t need to be issued as often (as discussed above) I was discussing a tool improvement yesterday with one of our engineers, shout out to Don Gilbert for being a weekend warrior, and the conversation subtly shifted back into this debate. He looked at me and said, “We don’t want to delay a release for perfection.” My immediate response was, “We do want to delay a release for purpose.”
What I meant by that statement was simple: When releasing a product into the market, or really releasing anything (marketing materials, sales decks internally, literally anything) we should release intentionally. And if there’s something fundamental that needs to be improved or changed before a release, then hold the release for a purpose. A specific purpose. In this way you’ll release early and often, but you won’t release a problem. If you have a real and definite purpose for delaying a release you’ll fix that reason and still release. It will still be fast and it will still be frequent. But it will be polished.
