,
4 tweets,
1 min read
Read on Twitter
Buried in the "deploy on Friday!!" argument is an interesting generalisation of 'crash-only' software; the idea that you should design features to fail *fast* so that you can detect and react close to deploy time.
I don't think this is actually possible in the general case.
I don't think this is actually possible in the general case.
Infrastructure software can go wrong sloooowwwwly, in ways that are triggered only by prod traffic. Wiithout any data, I suggest that for this class of bugs maybe 80% of them could be caught within three days, whereas only 30% of them might show up in the first 8-10 hours.
That's not a systematic problem, so much as it's endemic to software that manages resources. Not deploying on Friday just means that you want to keep your expected number of weekend bugs below a minimum, because weekends are _different_, which seems fine to me.
But as a general problem, asking not only "how will we tell if this is working?", but "how _quickly_ can we tell if this is working?" is a great design review prompt, and a goal worth optimising some for.
