Recently while giving a talk I asked for a show of hands on how many people checked multiple times that their door was locked before leaving home. Expecting myself to be the only one, I was surprised when just about everyone raised their hand.
Seems many of us exhibit some anxious behavior around whether “everything is OK” around the house. So… why do we do that, and how can we reduce how much we do it and the impact of doing it on our lives?
Of course, double-checking that our door is locked isn’t about the door-it’s about the consequences or the effects. If the door isn’t closed properly my cat might run out, or somebody might steal my stuff.
What can we do about these anxieties? A popular solution is monitoring. Alarm systems, smoke detectors… these kinds of things have been around for a long time. By not going off they tell us that something isn’t broken. Which beats checking each door and window whenever we’re anxious about security.
Monitoring is also traditional and critical with IT systems. What developers have usually done in web apps that lack any sort of structure reflects that obsessive mentality: they triple-check everything to make sure nothing breaks or is broken. The problem is this slows them down significantly because it takes extra time and focus.
The idea with monitoring is to get comprehensive systems and tests in place so you don’t have to worry-then you can move fast. This is like having an insurance policy on top of your alarm system, which further reduces anxiety because if something happens “you’re covered” and the risk associated with failure is less. You can move fast and not worry because if something goes wrong your monitoring will tell you.
In today’s DevOps world, how do we move faster and still detect problems before our customers do? How do we test things and fail quickly and move move move move move and still remain “not sloppy”?
The answer in my opinion is to implement systems that reflect what anxious people have been trying to do for years. Which is to reduce paranoia by putting systems in place that alert you when something goes wrong. I advocate focusing on these kinds of systems before a team attempts to “move fast” by deploying code multiple times per day or have multiple developers pushing new code daily, and so on.
Fortunately that’s a lot easier in IT than in everyday life, because we can monitor software pretty systematically. Most anxious people don’t have a system that tells them whether their oven is off or not.