Digital Powertools

Digital Powertools

Make your tools easier, faster and better

F*ck it, ship it.

This tweet by Mike Veerman sparked a bit of a debate on Twitter in October. People lamented that most organisations only ship once per quarter (or less!) driven by, amongst others, a disconnected management and arduous deployment procedures.

I agree with the sentiment of the tweet, but it needs a bit of nuance, since people interpret "to ship" in multiple different ways. Some people interpret it as "to release a feature to your customers", others as "to deploy code to a production environment". I'm in that last boat. If I were to interpret it as releasing, I would even recommend the opposite to Mike's tweet and release only on a quarterly basis.

Because people hate change, especially the big in-your-face kind of change of new features and designs. If you release UI changes very often, people are going to get frustrated because they won't find the feature they're looking for. The visual clues they're used to are suddenly totally different. They have to change their workflows because you decided to replace an old feature with a "better" one. Your customer success team will have a hard time keeping track of all changes and the documentation will go out of date really quick. They won't find what they're looking for in the product. They'll get annoyed with your team and your product.

So when you finally release a new bundle of features to your customers, it's the ideal moment to make some noise about your product. Send out a press release every week, and the newspapers will stop covering your releases real quick. Send out one big press release a year, full of shiny new things your product can do, and the press in your business area will be more than happy to cover it. A release is the perfect marketing event.

So no, don't release shiny new features to your customers every day or week or month. Release them in bigger batches, but... (there's always a but, isn't it) don't let these customer-facing release cycles influence your development cycles either! If there's one thing your customers hate more than constant change, it's bugs that go unfixed for months at a time, especially if they have a big impact on the customers workflows. You really want to get the fix out there as soon as possible. Don't wait for the next feature release that may be months away. No, immediately deploy the fix to production when it's ready and your CSAT will be through the roof.

So on one end, you want to deploy as much as you possible can. On the other end, you don't want to give users access to the new things before they are ready. There are many different ways you can handle this situation, all with their own pro's and con's. My personal preference is a technique called "dark launches".

In a "dark launch" you deploy all the finished code to production as soon as you can. Code that should not be accessible is hidden behind a concept called a "feature flag". A feature flag is a boolean variable that indicates whether the protected code is available to a customer.

This approach has a couple of benefits. First of all, you can give customers early access to certain features without opening them up to everyone. With the early feedback from these key partners, you'll know whether the feature is good or if it may need some quick adjustments before you show it to the broader public. If you're dogfooding your product, early access for internal teams and their feedback can even save you from a public embarrassment when the feature is finally open to everyone.

As a second benefit, your new code is integrated with the existing code on the main branch all the time. Conflicts and misunderstandings about boundaries between components are quickly discovered and easily solved. There is no huge "merge conflict hell" because multiple people changed the same code at the end of the development cycle. And besides totally new code, fixes for existing code can be merged in all the time as well.

The last benefit is also a bit of a prerequisite for this strategy to work though: you will (need to) build a firm confidence in your processes. You're merging new code on a very regular basis, the amount of code on the main branch that never ran on production can grow really quickly. When there's a lot of changes, people get anxious. It gets more difficult to assess the potential for bugs and errors in the large changeset, so they want to make sure it's all well tested. But by doing so, they're holding the deploy back even longer and making the new changeset even bigger. If you want to add new code continuously with confidence, build out a solid QA process with big suite of automated tests. And since you want to deploy on a daily basis, you can't afford to spend 6 hours fixing your environment after every deploy.

When something in the deploy process breaks often, when it hurts, you fix the process in the best way possible. And let's face it, most of the issues during a deploy will be caused by human mistakes. If the process contains 10 pages of CLI instructions, the human will fail. And the logical improvement is to take the human out of the equation. After fixing the mistakes made during the frequent deploys, the process may include just a single manual step: click a button on a web page to kick off the process.

In the end, deploying your code on a daily basis allows you to release your features on a much slower cycle, in a controlled, stress free way.