In this article we’ll discuss what Roman military tactics and modern security practices have to do with protecting users from software defects.
What is Defense in Depth?
Defense in depth is a term originally used to describe the Roman military’s practices of making intentional strategic retreats in order to regroup and counterattack invading armies on their own terms and in their own territory.
Applied to software quality, defense in depth involves setting up a series of inspections designed to prevent or detect quality issues before code gets to production. Each step has a only a chance that a defect will be detected or prevented, but together, they drastically reduce the likelihood that a defect makes it to production.
This is different than the security concept of defense in depth which commonly refers to redundant layers of security in network and application design. However, you can clearly see the similarity in philosophy – Instead of layering security to try reduce the odds of an attacker breaching all layers, we’re adding checks throughout the process to reduce the chance that a defect evades all of them.
A Caveat on Effectiveness
In order for defense in depth to work, detection of defects has to result in preventing them from moving further. This seems obvious, but it’s important to talk about.
If your focus is to get code to production at all costs, finding a defect only tells you what some of the defects already heading to production will be.
Additionally, you can say that you want to do thorough testing, but if there’s a discernible rush to production and strong forces at work to get there (which often is the case around deadlines), confirmation bias will be in full effect and the checks you have will be biased towards approving things.
In order for defense in depth to be effective, your team and organization at large must be truly bought in and want to find bugs.
Series Overview
Over the course of this article series, we’ll take a look at how a multitude of checks can be used to improve software quality by reducing the chance that a defect can escape detection before entering the wild.
We’re going to focus primarily on the following major areas:
- Design & Development
- Review & Formal Testing
- Deployment & Monitoring
Each of these areas as multiple topics inside of it which each deserve an article of their own and I will aim to publish at least one article in the series each week, ending likely in Q1 of 2020.
This series should have a broad appeal and so I will try to keep example code to a minimum and use JavaScript and .NET technologies in my examples as my readership tends to be in one or both of those two camps.
If there’s a specific aspect to software quality or question you’d like me to address as part of this series, please let me know – chances are it can benefit someone else as well.
Cover Photo by Reuben Farrugia on Unsplash
