Still massively missing the point.
"Why risk it if you don't have to?" <- is the dead tell.
Risk pervades everything we do. Every decision you make has risk on both sides, and humans are incredibly bad at reasoning about risk. https://en.m.wikipedia.org/wiki/List_of_cognitive_biases …
That statement makes it sound like the equation is simple:
deploy == risk
no deploys == no risk
Indeed, this is how many people do think about risk; and if you zoom far enough in on any single deploy, it may even seem true. Any individual deploy *may* temporarily elevate risk.
But a system is not made up of a single event, and that is a poor way to evaluate risk.
🐌 What of the risk of delaying deploys?
🕷 What about the risk of batching up multiple changes by multiple devs?
🐛 Or the chances of forgetting what was in those diffs, days later?
🦟 What about the risk generated by doing something different from your normal process?
🦗 Or the risk of decoupling the development of code from delivery to users?
🐞 And what risks do you run by *not* fixing bugs or delivering any value to users for 20% of every week?
Everything we have learned about managing the risk of software deployment and delivery tells us that the best way to manage risk is to deploy one changeset at a time, as swiftly as possible.
The risks of not deploying on Fridays are extremely high, despite the handful of cognitive biases that conspire to make them invisible.
Only you can decide which is higher risk for your org at this point in time. What matters is that you see clearly how to reduce that risk.
You can follow @mipsytipsy.
Tip: mention @threader_app on a Twitter thread with the keyword “compile” to get a link to it.
Enjoy Threader? Sign up.
Threader is an independent project created by only two developers. The site gets 500,000+ visits a month and our iOS Twitter client was featured as an App of the Day by Apple. Running this space is expensive and time consuming. If you find Threader useful, please consider supporting us to make it a sustainable project.