The other day I mentioned my worst customer-impacting mistake ever — marking a heavily used object with the wrong threading model. A number of people commented to me that it was unusual to see a developer own up to such a mistake in a public forum. (Surprisingly, no one pointed out that it was also odd to do so while talking like a pirate.)

Well, it’s because of restaurants, believe it or not.

My father has been in the restaurant business for many years. Something he taught me at an early age is that one measure of the quality of a restaurant is how few mistakes they make, but a more important measure is how they treat the customer once a mistake has been made. Do they apologize, take responsibility, and immediately act to correct the mistake, or do they engage in cover-ups, blame-shifting and foot-dragging? I don’t go back to the second kind of restaurant, no matter how good the food is.

The software industry is no different. Here are four aspects to consider:

• Customer focus: Most importantly, when a customer-impacting mistake is made it is necessary to inform customers of the problem, take responsibility and if possible fix the problem, period. If that means they think I’m a bozo, I’m cool with that. Preventing customer pain is a whole lot more important than anyone’s opinion of me.
• Public image: Just because I don’t walk up to you and say “Hi, I’m Eric and I’ll be developing your application infrastructure and development tools this evening” doesn’t mean that said tools aren’t developed by humans with names and faces! Too often companies such as Microsoft are perceived as faceless monoliths, a few dozen six-story sea-foam-green glass boxes that mysteriously transform money into code. This misperception belies the reality; I work with dedicated and talented people who care deeply about making their customers more productive. All those people — all the testers, developers, managers, writers, etc, — deserve credit for shipping great software. And when someone really screws up, well, adult humans should be capable of the occasional mea culpa.
• Evolution of the industry: The engineers who sign off on a bridge are quite literally putting their names on the line. If software engineering is ever going to evolve from a craft to a fully-fledged engineering discipline, we need to start acting like engineers. (And as a Waterloo math major, that’s hard for me to say with a straight face, believe me!) If I’m not comfortable with signing on the line and saying that this code is ready for prime time, then I shouldn’t be shipping it.
• Diffusion of knowledge: Finally, the best mistakes to learn from are other people’s mistakes. Learning from your own mistakes sucks, not to put too fine a point on it. If I can help other people learn from my mistakes, so much the better for the world as a whole.

Coming soon: Eric’s least customer-impacting mistake ever. But that will have to wait until this evening, because my band has a gig at our Product Unit meeting this afternoon. Yes, the Trinity Team has their own rock band! We are “Red Pills Reloaded“, aka “Rage Against The Blue Pills“.

There was some discussion in the comments about the $DATA stream vulnerability that had been recently discovered, but I don’t think I’ll summarize it here, aside to say that it was fundamentally a “fail to the insecure mode” error.

The Visual Studio Tools for Office team used code names that were all from the “Matrix” series of movies, and it was a fun theme. We put together a cover band — I played keyboards — and did a lot of Steely Dan and other 1970s era rock, which was a lot of fun. Choosing a name inspired by The Matrix was an obvious choice, and now I am intensely disappointed that “red pill” has since been co-opted by misogynist jerks; I can’t in good conscience wear my The Red Pills t-shirt in public.