How do you prevent an app from breaking?
Do you do it with automated tests? Does that work? When doesn’t it work? What do you do when automated tests don’t work?
How about cases where automated tests might work, but you don’t have them? Suppose you inherit a system with 8% test coverage. What do you test first?
These are some of the questions we address in “Parrot Emergency! Analyzing Risk in Software Systems.” Earlier this month, I presented this workshop at RubyConf with my colleague, Lauren Campbell. Although it was RubyConf, the workshop itself is language-agnostic and applies to software systems in all stacks.
The goal: communicate a strategy for determining when and how apps will break. Here’s the key though: the strategy needs to be both accurate enough to be useful, and simple enough to be used.
Here’s how it goes: we put you on a team with 4-6 other software engineers. Then, we show you the class diagram for a complex and critical software system: an emergency triage system for parrots. That’s right: every poorly parrot gets a little parrot harness that monitors their vital signs and helps vets determine who needs attention first.
Your job, with your team: make sure the system works. You won’t be writing actual code, but you will be:
- Identifying all the risks in the system where stuff could go wrong
- Assessing which of those risks you should prioritize for mitigation
- Matching the right mitigation tactics to each of the risks, in priority order
And of course, just like a real software project, time is of the essence. Both because the workshop is only two hours long, and also because fictional parrot lives are on the line!
Here is a video recording of the workshop run from RubyConf. We want to offer a huge, public thank you to Abigail Phoenix at Ruby Central and the Ruby Conf team for the incredible work they did to throw this year’s inaugural remote Ruby Conf. They managed to preserve the content of the event with they talks and workshops, but they also managed to salvage some of its soul with preparatory speaker events and karaoke rooms. Seriously, hats off to this whole team.
We have attempted, with the above recording, to make it as easy for you to follow along as possible. In case you’d like to watch the recording of the workshop and work through the exercises yourself:
- Here is the agenda to help you follow along (we paused the recording during those periods where groups were working on an activity)
- Here are the slides, so you can follow along with the (short!) lecture portions in high-resolution.
- Most importantly, here is a template version of the class diagram that each group used in the workshop. You can use this to make your own copy to do the activities on!
This workshop, like everything on this blog, carries a CC-by-SA license. Feel free to share, or even run, this workshop with your team, but please include attribution to Chelsea Troy and Lauren Campbell, and please include a link to either this blog post or the YouTube video in the attribution.
If you really wanted, we’d be happy to come and run the workshop for you, provided we can find an appropriate date.
In the meantime, I hope you find the material helpful, and I cannot wait to hear how it helps your team manage their software system risks more effectively :).
If you liked this piece, you might also like:
The ongoing Advanced Programming with Python series
This recent interview on Greater than Code about Techtivism
The Designing a Course series about…well…designing, among other things, class activities. This workshop grew out of an activity I designed for my Mobile Software Development class!