Sometimes I go on project archeological digs with my clients through their projects, often focusing on their code bases. We sometimes run a “code bazaar”, where we set up a half-dozen machines with code to dig through, then walk in pairs from machine to machine, digging and taking notes. During these digs, I institute a key rule:

Ask “why”, but never answer.

What kind of “why” question? Why, the most perplexing one: Why the $%@# did we do this?! We feel free to ask the question, but we don’t answer it. If someone feels the impulse to answer it, someone says, “We don’t go there.”

This rule serves a dual purpose. By never answering “why”, we avoid the exercise devolving into wallowing and blaming. We avoid counter-productive actions like justifying, going on the defensive, and shifting the blame. This allows us to have an open, frank discussion of the project in a safe environment. Why, then, do we permit people to ask “why”? Simply put, we don’t deny human impulse.

You’ve experienced it. You’ve reviewed code, screamed “What the fuck?!” and shook your head. I recently read code that made me angry enough that I had to stand and walk around to calm down. (It assigned a field to itself. Don’t ask.) I understand the power of the impulse to recoil, then demand of the universe how it could allow such a thing to happen. For this reason, we permit each other to ask “why”, and even to do so in a loud, obnoxious, pained tone of voice. We simply don’t answer that question, and if someone tries, we remind them that “we don’t go there.”

Try it the next time you have to rummage through code, documents, or some other project artifacts as a group. Ask the group to agree on one rule: you can ask “why”, but you can’t answer it.

This principle is one of many tools I use to survive legacy code. Click the logo if you need to learn more!