Meetings

The Other Kind Of “Easter Egg”

“The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ (I found it!) but ‘That’s funny …’”
― Isaac Asimov

We all know about “Easter Eggs” in software. Those cute, fun little pieces of personality that the developers hide in the code. If you hit the right sequence of keys or actions, you get to see them.

But the term can also be used as a gerund. “Easter Egging” can be a valuable, albeit non-scientific technique. In short, “Easter Egging” means trying a bunch of things which “might work” or “have worked” or “look like they could work” in order to fix a problem which defies logic.

In other words, if the problem makes no sense, try to solve it with nonsense. That’s probably too harsh a description, but what you’re trying to do here is two things at once in order to figure out why your system is puking on its shoes.

First, you are trying to diagnose the problem symptomatically. Does it break for all users or just certain ones? Does it break for guests as well as logged-in users? Do all records exhibit the problem, or just certain ones? And so on. The difference between Easter Eggin’ and straight-line debugging a problem or ticket is that you’re going outside the parameters of the problem as reported. You’re trying to determine the scope of the actual problem by throwing a wide variety of stimulus at it.

The other thing going on is you’re trying to make cognitive leaps by observing the behavior of the system under conditions which may - or may not - incite the bug. So rather than staring at your code line-by-line hoping for “magic to happen”, you’re poking and prodding the system in the wild (or in your development server environment), and looking for what causes the troublesome behavior so you can trace it back to its source.

Why is Easter Eggin’ of use when you can just use a debugger or other tools to attack a problem using traditional (and less weird) techniques?

One advantage is that if you are a skilled at Easter Eggin’ you can fix problems in code you may not own. Or code or haven’t worked on. Or code you haven’t worked on in years. The technique is code-agnostic and experience-indifferent. You can even remote-debug with the technique with another engineer on the phone. It will seem odd, asking him or her: “What happens when you do this? Now try doing it this way - what happens?”. But once you get a handle on what the system is doing, then you can look at actual code and try to figure things out.

The other advantage is that it can be faster and more comprehensive than linear debugging. Iteratively changing code and re-running tests can eat up a lot of time. Whereas just throwing different conditions and situations at the code to see what incites the problem, and how it behaves, can be done in a few minutes, and it will give you a better grasp of the scope of the problem. For instance, if you just use linear debugging you will of course find the line that causes the reported bug. What you may not find is other conditions which may cause the code to break in other ways or other places. Whereas if you debug the behavior first, then you are more likely to catch related or tangential issues.

Easter Eggin’ isn’t something that gets taught in school and it’s not even a formally recognized technique. But it borrows from other phraseology such as “recon by fire” or “beating the bushes”. In these cases you are trying to scout a position or drive game into the open more or less by guessing where they’re hiding, and using some kind of force to drive it out into the open. The same concept applies to trying to root out a pesky bug.

The extra special bonus of this is the looks you get when you solve an “impossible” problem that’s been brought to you in mere minutes by doing something so outwardly non-sensical.