Shipping will try to kill you<\/h2>\n
The scramble to get that one last feature done, the compromises, the sinking feeling when we realise something major is broken, the post-mortems … it\u2019s agony, but if it was easy everyone would do it. Shipping exposes mistakes. We\u2019re nervous about it and our natural reaction is to do it reluctantly and infrequently, which actually carries higher risk, causing more reluctance in the future.<\/p>\n
The cost of shipping is approaching zero<\/h2>\n
Not too long ago, shipping software involved actual ships, disks and printed manuals. It happened perhaps once a year. Bug fixes weren\u2019t automatic over the internet like today. Everything was slower and more controlled. The cost of shipping was massive, the consequence of a mistake was large. Today, the cost of software deployment has approached zero. Most people can deploy in seconds or minutes with a single command or button click. With a little thought you can do that without your customers noticing, and with automated monitoring you\u2019ll find out immediately if something goes wrong.
\nHowever, despite the cost of software deployment approaching zero, many people still ship software guided by very old habits.<\/p>\n
Shipping cadence defines your company<\/h2>\n
The cadence at which you ship defines your company. A yearly cadence results in a very structured approach to the design->build->test cycle. A few months of building, while the rest is spent fixing. Engineers can join and leave before seeing their hard work end up in the hands of customers. The approach to design becomes one of anticipating all possible needs, rather than focusing and iterating on the important ones.<\/p>\n
Obstacles downstream propagate upstream<\/h3>\nAn obstacle downstream propagates upstream. If you’re not allowed to implement new ideas, you stop having them.
\n– Paul Graham<\/a><\/cite><\/p><\/blockquote>\nThe right approach to shipping has a positive influence on your company’s productivity and your team’s happiness and job satisfaction. Shipping infrequently is an obstacle. Ship slow, and you’ll introduce challenges that push you to ship even slower. Ship frequently, and see positive effects everywhere in your company. For example, let\u2019s examine how varying shipping frequency can affect wider company behavior with a simple scenario such as handling a basic request from a customer.<\/p>\n
![\"Time](\"https:\/\/intercom.com\/blog\/wp-content\/uploads\/2013\/05\/time-to-production-behavior.png\" "\\"time-to-production-behavior\\"")
<\/div>\nLet\u2019s say a customer gets in touch to say \u201cNo matter what I do, I cannot save my name correctly, I think it doesn\u2019t like hyphens.\u201d<\/p>\n
In a company where you ship continuously, you see this and think \u201cSimple \u2013 I\u2019ll tweak a test and a regex pattern, get a quick code review from my teammate, merge my pull request to master, and one minute later when it\u2019s deployed to production, reply to the customer: \u2018Sorry about this, it\u2019s fixed now, thanks for letting us know.\u2019\u201d<\/p>\n
They\u2019ll reply: \u201cWow, thanks for fixing so quickly\u201d. High fives all around!<\/p>\n
If we stretch the time to production (TTP) out a little, even to 10 minutes, the behavior changes. You either do the same, but reply saying it\u2019ll be fixed with our next deploy (probably 10 minutes) \u2013 or you wait, so that you can communicate with certainty. The waiting is time where you\u2019ll shift focus to something else, but have the baggage of having to follow up. Perhaps you\u2019ll think, I\u2019ll have a quick coffee, then move on to something else afterwards. Even though your deployments are entirely automated, you lose time because of waiting and losing focus.<\/p>\n
If TTP is hours, the behavior changes again. No longer can you say with certainty when the change will be out there, so you\u2019re tempted to batch up with other similar small changes. You postpone replying until you get time to do it, sometimes forgetting about it. You\u2019re less likely to take prompt action and you pay some mental cost for having it on a todo list. Since getting to production takes hours now, your team will start restricting to morning-only deploys, so miss that slot and it means further delays.<\/p>\n
If TTP is days, it exacerbates that further \u2013 perhaps you\u2019ll reply \u201cThanks for letting us know. We\u2019ll fix this in our next sprint.\u201d It gets bundled in with a whole load of other small low-priority items, you spend more time debating estimates and priorities than the first guy took to fix it and reply to the customer. Miss the beginning of week deploy window and further slippage. The larger releases bring higher risk, you\u2019ll tell your customer it\u2019s fixed, only to later require rolling back because of a separate change. Your bug database gets bigger and bigger, full of little details that you\u2019ll probably never fix.<\/p>\n
When TTP is weeks, it exaggerates that even further \u2013 perhaps you\u2019ll reply \u201cSorry about this, I\u2019ll let the development team know,\u201d or something that from your customer\u2019s standpoint sounds equally lame. Deep down you realise nothing will be fixed, and the job of talking to customers becomes a cost or hassle, rather than an opportunity to improve your product and nurture happy, loyal customers.<\/p>\n
Shipping continuously<\/h2>\n
Better approaches to writing or testing software help us iterate more quickly and confidently, but the benefits are quite local to engineering teams. Continuous shipping, on the other hand, touches all parts of your company, as do the benefits and the behaviors it enables and encourages.<\/p>\n
Good products are a side effect of combining great people<\/a> with an idea in an agile, dynamic and collaborative environment that helps those people to kick ass. Your attitude to shipping is a big part of that environment you create.<\/p>\nShipping breathes life into how we think. The feedback loop helps us learn, gain confidence in making quick decisions, and as a result build momentum. Momentum in product improvements excites and engages our customers. Quickly seeing the benefits of our hard work motivates us to do more. Building a team where people’s hard work can quickly have an impact, with minimal friction, is empowering and it attracts others, so hiring gets easier.<\/p>\n
![\"Shipping](\"https:\/\/intercom.com\/blog\/wp-content\/uploads\/2013\/05\/shipping-brings.png\" "\\"shipping-brings\\"")
<\/div>\nShipping continuously isn\u2019t an achievement you unlock and then move on. You\u2019ve got to constantly obsess about it<\/a>. If you believe in the benefits it brings, you\u2019ll be driven to shrink 20 minutes down to 1 minute or less. You\u2019ll consider \u201cability to ship\u201d as an equal to \u201cdoes it scale\u201d when building new systems. And you\u2019ll do all of that that because of the life it breathes into your company and your product.<\/p>\n
An obstacle downstream propagates upstream. If you’re not allowed to implement new ideas, you stop having them. The right approach to shipping has a positive influence on your company’s productivity and your team’s happiness and job satisfaction. Shipping infrequently is an obstacle. Ship slow, and you’ll introduce challenges that push you to ship even slower. Ship frequently, and see positive effects everywhere in your company. For example, let\u2019s examine how varying shipping frequency can affect wider company behavior with a simple scenario such as handling a basic request from a customer.<\/p>\n Let\u2019s say a customer gets in touch to say \u201cNo matter what I do, I cannot save my name correctly, I think it doesn\u2019t like hyphens.\u201d<\/p>\n In a company where you ship continuously, you see this and think \u201cSimple \u2013 I\u2019ll tweak a test and a regex pattern, get a quick code review from my teammate, merge my pull request to master, and one minute later when it\u2019s deployed to production, reply to the customer: \u2018Sorry about this, it\u2019s fixed now, thanks for letting us know.\u2019\u201d<\/p>\n They\u2019ll reply: \u201cWow, thanks for fixing so quickly\u201d. High fives all around!<\/p>\n If we stretch the time to production (TTP) out a little, even to 10 minutes, the behavior changes. You either do the same, but reply saying it\u2019ll be fixed with our next deploy (probably 10 minutes) \u2013 or you wait, so that you can communicate with certainty. The waiting is time where you\u2019ll shift focus to something else, but have the baggage of having to follow up. Perhaps you\u2019ll think, I\u2019ll have a quick coffee, then move on to something else afterwards. Even though your deployments are entirely automated, you lose time because of waiting and losing focus.<\/p>\n If TTP is hours, the behavior changes again. No longer can you say with certainty when the change will be out there, so you\u2019re tempted to batch up with other similar small changes. You postpone replying until you get time to do it, sometimes forgetting about it. You\u2019re less likely to take prompt action and you pay some mental cost for having it on a todo list. Since getting to production takes hours now, your team will start restricting to morning-only deploys, so miss that slot and it means further delays.<\/p>\n If TTP is days, it exacerbates that further \u2013 perhaps you\u2019ll reply \u201cThanks for letting us know. We\u2019ll fix this in our next sprint.\u201d It gets bundled in with a whole load of other small low-priority items, you spend more time debating estimates and priorities than the first guy took to fix it and reply to the customer. Miss the beginning of week deploy window and further slippage. The larger releases bring higher risk, you\u2019ll tell your customer it\u2019s fixed, only to later require rolling back because of a separate change. Your bug database gets bigger and bigger, full of little details that you\u2019ll probably never fix.<\/p>\n When TTP is weeks, it exaggerates that even further \u2013 perhaps you\u2019ll reply \u201cSorry about this, I\u2019ll let the development team know,\u201d or something that from your customer\u2019s standpoint sounds equally lame. Deep down you realise nothing will be fixed, and the job of talking to customers becomes a cost or hassle, rather than an opportunity to improve your product and nurture happy, loyal customers.<\/p>\n Better approaches to writing or testing software help us iterate more quickly and confidently, but the benefits are quite local to engineering teams. Continuous shipping, on the other hand, touches all parts of your company, as do the benefits and the behaviors it enables and encourages.<\/p>\n Good products are a side effect of combining great people<\/a> with an idea in an agile, dynamic and collaborative environment that helps those people to kick ass. Your attitude to shipping is a big part of that environment you create.<\/p>\n Shipping breathes life into how we think. The feedback loop helps us learn, gain confidence in making quick decisions, and as a result build momentum. Momentum in product improvements excites and engages our customers. Quickly seeing the benefits of our hard work motivates us to do more. Building a team where people’s hard work can quickly have an impact, with minimal friction, is empowering and it attracts others, so hiring gets easier.<\/p>\n Shipping continuously isn\u2019t an achievement you unlock and then move on. You\u2019ve got to constantly obsess about it<\/a>. If you believe in the benefits it brings, you\u2019ll be driven to shrink 20 minutes down to 1 minute or less. You\u2019ll consider \u201cability to ship\u201d as an equal to \u201cdoes it scale\u201d when building new systems. And you\u2019ll do all of that that because of the life it breathes into your company and your product.<\/p>\n
\n– Paul Graham<\/a><\/cite><\/p><\/blockquote>\n<\/div>\nShipping continuously<\/h2>\n
<\/div>\n