BrainBlog post for Faros AI
Jason Bloomberg of Intellyx challenges the assumption that all code must be tested before deploying it to production.
“If everything seems under control, you’re not going fast enough.” ― Mario Andretti
When we drive our cars, safety is paramount. We moderate our speed, use our mirrors, and drive defensively. If conditions require us to slow down, then we slow down.
Unlike legendary racecar driver Mario Andretti, our goal is to get to our destination as safely as possible.
For Andretti, however, the goal is to win the race. Safety is but a means to an end, as crashing is a surefire way to lose.
This contrast between the two extremes of automobile driving has a close analog in software development.
For software, safety refers to reliable, bug-free code. Sometimes safety is paramount, like with bank transaction processing or satellite software. In such situations, delivering code that is optimally reliable is the main goal, and if it takes more time to deliver it, then so be it.
In other situations, software velocity is a top priority, for example, with web-based companies or digital offerings in general. These organizations’ competitiveness – and thus, their survival – depends upon delivering changes to code quickly.
Both perspectives are valid, as they both focus on managing the risks inherent in software development – the risks of delivering broken code vs. the risk of delivering code too slowly to meet the competitive requirements of the business.
What, then, is the best way of trading off velocity and safety? Once we answer that question, then another question becomes paramount: how can we improve both velocity and safety at once? Understanding the tradeoff is one thing, but we really want both at the same time.
After all, that’s how Mario Andretti won his races – and lived to race another day.
Click here to read the entire article.
