After a couple of major production fires on our analytics pipelines that required us to drop everything and push through several migrations, my fellow engineer Zach and I looked at each other and admitted that “this was terrible, but things are actually much better now” – and so, the term “Crisis Driven Development” was born. We shaped up our ideas around the concept enough to talk about it at an engineering all-hands at Flatiron Health, and followed up with a couple of blog posts.
Zach’s post (the first part of the saga) focuses on how to be in a good spot to actually keep pushing forward during production fires instead of rolling everything back, and emerge on the other side in a better state.
The second part that I wrote then takes a step back and thinks through what makes ‘Crisis Driven Development’ so successful, and how we can apply those principles to a regular development cycle instead of a crisis – a controlled burn, so to say. And while none of this is entirely new, I do like how it can introduce a slightly different way of interacting and working together than the go-to mode of agile sprints and tickets. Let me know what you think – feel free to comment here, on Medium, or hit me up on Twitter.
Sam Bail 