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."


   







Comments

Post a Comment

Popular posts from this blog

Bookshelf: UNIX A History and a Memoir

-
Image
  A man page will give you, in black and white, specific information about UNIX. Brian Kernighan's new book adds color and depth about UNIX you won't find anywhere else. I'm not a gray beard (yet), but I imagine they would plow through the book knowingly, but at the same time, learn a few things. Those new to UNIX -- recent college grads or those experimenting with Raspberry Pi -- would be better off starting with Chapter 8 which describes more relatable events and the descendants of UNIX, including Minux and Linux. It's when they start to ask questions like "Where does UNIX come from?" and "Why is Gamora grep?" that they should start from the beginning: Bell Labs, 1969. Kernighan opens with a birds-eye-view of Murray Hill New Jersey, zooms in on the buildings, the offices, the significance of Center 1127, and offers a brief look at some of the key players there. As I progressed through the book, the two factors that made UNIX not just possible, bu
Read more

Bookshelf Classic: The C Programming Language

-
Image
My first job had me programming in Microsoft BASIC for the IBM PC (DOS).  BASIC worked well enough, but its limitations were clear.  The language was interpreted and therefore slow.  More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement.  Anyone who has read Dijkstra knew  GOTO was a bad thing . Having learned a structured language in college ( PL/I ), using BASIC felt unnatural.  When a C compiler became available for the PC, I saw a chance to improve and modernize our software.  The problem was selling the idea -- a problem made harder because I wasn't fluent in C. "It would be a staffing problem.  Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager. The argument was strong as my knowledge of C was weak.  But I knew that C, by design, was a small language and thus easy to learn.  "It has about 30 keywords," I proffered to another manager. U
Read more

Connections

-
Image
Opening a drawer in my hotel room in Toronto, I found this.  I worship at the altar of tech, but I imagine the reaction between two priests might go like this: Mormon Priest:  "At least we're wireless!" Catholic Priest: "And from the very beginning too!"
Read more