The Art of Making Misteaks


A broiled prime rib steak
Ask forgiveness, not permission.  -- Admiral Grace Hopper

Move Fast and Break Things.  -- Mark Zuckerberg

Don't repeat old mistakes. Make new and innovative ones. -- Me

These quotes are variations of a theme: don't be afraid to make mistakes. There are differences though. In the case of Admiral Hopper, she knew things moved slowly in a military bureaucracy, and recommended that if you have a good idea, go ahead and pursue it. With Mark Zuckerberg, the early days of Facebook required constant and rapid innovation, although today, the "break things" part seems reckless, and has indeed produced undesirable consequences.

My take is that mistakes happen, and when they do, make it a new one. Repeating old mistakes is possibly the worst kind of mistake, suggesting that nothing was learned or addressed. Making no mistakes at all, however, indicates that you and your team aren't trying. Or worse, that your work environment shoots the messengers, throws staff members under the bus, and otherwise sees mistakes as failures.

In one setting, I listened to a senior developer and QA argue over a bug. QA found the bug in two systems, and counted it as two defects. Dev tracked the bug to a common library routine, and argued the defect should only be counted once. I sided with QA (even though I was a developer) because if the user sees two bugs, then there are two bugs.  The work environment was such that Dev was being penalized for every defect count while QA -- I suspected / joked -- was being paid a bonus for every bug they invented discovered.

There was also a "No New Bugs" period we endured. Decreed from high up, it was a slogan with the goal of zero defects. But developers are cerebral, and know zero defects is a ridiculous goal. Put differently, when a coach says "Give me 110 percent!" football players will let the words inspire them and raise their level of commitment, whereas developers will see 110% as nonsensical because by definition, giving 100% is already giving your all. Bugs will creep in regardless of talent or process. What's important is how you handle them.

When I mentioned that instead of aiming for zero defects, that we should strive to make new innovative mistakes, I was met with blank stares. There was no "Can you elaborate?" Or even a jokey "How do you make a test case for that?" Instead, they went back to "No New Bugs."



Popular posts from this blog

Bookshelf: UNIX A History and a Memoir

Bookshelf Classic: The C Programming Language