Have you ever deployed a feature on production that immediately caused a series of bugs? I once made a change that sent unnecessary invoices to hundreds of customers. The code was tested and peer-reviewed, but I forgot to deal with an edge case. That day the customer service team was bustling. What should I have done differently? Answers lie in the learnings of Stoicism, a practical philosophy founded in Athens in the early third century BC. Stoics live their life following principles and virtues that help them navigate problems and setbacks. Let’s see what can Stoics teach developers.
One of the most expensive software bugs happened during the launch of an Ariane 5 rocket in 1996. After lift-off, the rocket flipped 90 degrees in the wrong direction, which triggered self-destruction. The problem: a 64-bit floating-point number was cast into a 16-bit number1. Murphy’s law state that anything that can go wrong will go wrong2.
That’s it bugs will happen no matter how talented you and the team are. We can’t predict all special cases and how people will push our programs. Also, it’s impossible to build anything without blindly trusting abstractions and third-party systems. These are things out of your control. You can’t control bugs, but you can control how well prepared you are to deal with them. For example, you could adopt a defensive programming stance and anticipate bugs during coding or code reviews. Furthermore, you could use advanced languages (types, memory safety) and automated tests.
The Stoic developer will go through the practice of Premeditatio Malorum or pre-meditations of evils. The idea is to practice negative visualisations. The Latin phrase attributed to Cicero Nihil admirari translates to “be surprised by nothing”. Accepting problems and imagining the worst will invite you to be prepared for adverse outcomes.
It’s common for a team to produce a post-mortem after a setback to explain what happened. This is an excellent activity that will help you grow and learn from your mistakes. Stoics love introspection. To prepare for the worst, you could try doing a pre-mortem. Sit with your team and speculate about what can happen. How can your project fail? And then find out what could cause this to happen. For example, you could imagine that this new feature you are about to ship will cause a data loss. From here, you might want to test your database migration code or that your backups are operational.
We learnt two Stoic techniques that can help us write better and safer code. The practice of negative visualisation and pre-mortem will help raise confidence and prepare you for any potential issues. Problems will happen, but as Stoic developers, we can be prepared and face them with confidence and equanimity.
Finagle’s law extends it by stipulating that anything that can go wrong will go wrong — at the worst possible time. ↩︎