In the world of devops, we have complex software packages like Jenkins to take care of continuous integration of source, and intricate monitoring systems like Nagios and Icinga to keep an eye on the state of your servers. For notification of problems, however, sometimes the low-tech solution is best. Ladies and gentlemen, I present to you: Olivia the pig.

Olivia

Olivia normally sits on my bookshelf at the office. She's a toy from when my daughter Quinn was much younger, the star of the Olivia picture books that she loved back then. When Quinn decided she no longer wanted to play with Olivia, I gave Olivia a new home at the office, where she serves two important purposes in the web development department.

First, Olivia is a warning flag. She's a plush visual semaphore that says to all the developers "Something is wrong with the website source code." Like most shops (I hope!), we practice continuous integration of our source. The rule is that we must be able to roll out trunk to the production website at any time. Projects are done on branches, so that we don't have half-done work in progress committed to trunk. If code is committed to trunk, it's ready to go live at any time.

Olivia is the visual indicator that says "we cannot push to production." Normally, Olivia sits on my bookshelf. where she is only seen by me. When she is on top of my cube, she can be seen by everyone on our end of the building, including all of us developers. She can't be missed. If Olivia is out, Job #1 is to fix trunk and get it stable.

Olivia

Sometimes Olivia comes out intentionally, such as when we start a project merge to trunk. Olivia stays out until we've passed all our smoke tests, lest someone push out unproven code. Olivia tells everyone that things have not yet been proven to be stable.

Many organizations have physical semaphores like this. In the Perl 5 world, the person who is allowed to make changes to the master source tree is said to be "holding the patch pumpkin." Why did the Perl community come up with the name "patch pumpkin"? Chip Salzenberg explains:

David Croy once told me once that at a previous job, there was one tape drive and multiple systems that used it for backups. But instead of some high-tech exclusion software, they used a low-tech method to prevent multiple simultaneous backups: a stuffed pumpkin. No one was allowed to make backups unless they had the "backup pumpkin".

In Chip's example, the physical semaphore granted privileges. With Olivia, the semaphore of her being atop my cube indicates a problem. In both cases, they're low-tech but they work.

One Saturday afternoon at the office I had Quinn with me, and she asked why I had her old Olivia stuffed animal at work. I explained Olivia's purpose, and Quinn thought that was pretty cool. A little later she came back with the picture below. Change "Andy's computer" to "mission-critical web application that drives all company revenue" and she's got it right: If Olivia is out, the web app is broken.

Olivia

The visual semaphore is so simple and unmistakable, a then-eight-ear-old understands it.

But Olivia has a second purpose that I didn't expect. She's also a conversation starter, and so an ambassador for the department.

We web developers sit near a main entrance to the building, so many people walk by throughout the day. When Olivia is up on my cube, I'm often asked by a passerby why I have a stuffed pig up there. That's my chance to do a little department PR. I can tell the person about automated testing, continuous integration, and how we make sure that everything is going well.

I've become pretty good at cramming everything into a minute. I'll say something like "The source code to the website gets 100,000 tests run against it every hour on the hour, so we know we can always update it if we need to. If we discover that something is wrong, Olivia tells everyone that something is wrong. She's like an oil light on your car's dashboard."

I've found that people are generally interested in hearing about how we do the magic of running the website. Talking to people helps them understand what it is we do as developers, and helps squash the idea that we just sit around all day typing. They find out just what sorts of processes go into keeping business-critical systems running.

Does your organization have similar low-tech tricks as part of your process? Tell me about them in the comments.