The “broken windows” theory states that small problems can become bigger ones unless dealt with quickly. The theory suggests that people infer the rules of behavior from what they observe. It suggests that working hard to clean up a neighborhood by making repairs like fixing broken windows will help to deter further vandalism. In this article, I will discuss how this theory applies to network configuration.
It’s a thing of beauty to log into a network device and see named static routes. You may also see unused interfaces that are admin shut and consistently labelled with interface descriptions. This is a nerdy delight for most of us. The network administrator who owns this device really cares about configuration quality. If you review the device closely you can infer what the configuration standard might be. At the very least, you can understand the style of the administrator.
If you have to make configuration changes on this device, you know that if you don’t adhere to the existing style, your changes will stick out like a sore thumb. Worse still, there is the fear that your shortcut will be detected and you could be called to account for it.
So it’s quite likely that you’ll adhere to the existing style when you make your changes. Consequently, the updated configuration will maintain its readability and consistency, and the next engineer to work on this device will reap the benefits of your diligence. The positive side of the broken windows theory holds true and the “norm” of network configuration is maintained.
But what if you get a bit lazy, or you implement a temporary configuration change? As a general rule temporary changes are seldom removed. Perhaps we should call them poor-quality permanent changes. If you cut corners, the next engineer to work on this device will now have a choice of styles from which to infer a standard and they may choose to copy your shortcuts. Over the course of numerous changes and engineers, the configuration devolves to an unreadable patchwork of styles with no discernible standard. According to the broken windows theory, your configuration is chaotic and will only get worse because it signals to newcomers that nobody cares about it.
It could be argued that this whole issue shouldn’t be a matter of style. I agree that configuration policy shouldn't need to be inferred or reverse engineered. The proper way is to maintain a configuration standard and have a method for detecting configuration policy violations. In my experience, very few networks have this in place. You should ask your teammates or employer for configuration standards, and if they exist, follow them.
If configuration standards don't exist or don't apply, then it’s really tough to justify the return on investment for writing a new policy. This is particularly true if you're a consultant engaged to complete a specific task or project. In the absence of a policy, the best approach is to do no harm. The minimum bar for your efforts should be to implement your changes without making life harder for other engineers.
You should infer the existing style from the configuration and maintain it where possible. There may be times when you'll need to break from the existing configuration style. If you can justify a break in style, go for it. Any conscious decision is better than laziness.
Beyond configuration style, there is a strong argument to be made for fixing known issues or omissions quickly. An example is unnamed VLANs. Naming VLANs is such a simple thing to do, but the effort required to reverse-engineer the intent and use of an existing unnamed VLAN can be quite high. When you do discover the purpose of the VLAN, you should add the name yourself, or delete it if you can prove it is unused. This reduces the likelihood that another engineer will waste another few hours repeating your discovery work.
Despite all of the advances in networking, engineers still spend a lot of their trying to reverse engineer network configuration. Most of the documentation exists in the minds of other engineers, and IT folk rotate out of jobs relatively quickly. The more you can prune unwanted configuration and make it easy to read, the cheaper it will be for others to maintain your network.
Learn best practices and strategies for building and managing an enterprise network in the Networking Track at Interop Las Vegas this spring. Don't miss out! Register now for Interop, May 2-6, and receive $200 off.
Discover the benefits of scalable backbone and network services for application and cloud providers.
Network automation is gaining momentum. Here's how you can drive this powerful technology to its full potential.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
