Mistakes happen—just don't blame the system

We all make mistakes, and we all pray they don't get noticed like the false nuclear alarm in Hawaii. When it happens, the system is a false scapegoat.

Very simply, computers aren't smart enough to make mistakes (though AI may change that).

We create computing systems by describing rules and processes for the hardware to follow based on data that we provide. If things don't work as we'd intended, it can only be down to the wrong rules or incorrect data.

The recent Bitcoin crash resulted from an innocent mistake by a programmer. The very fact that this could have happened without quality control is the reason the cybercash is a long way from usurping the banking system in the way its converts would advocate.

So when we talk about quality control, we're talking about checking our own work. Whether you're engineering a simple change or building a program to land on Mars, the questions to ask are the same:

  1. Was the required outcome made crystal clear?

  2. Did the design fully address this outcome?

  3. Was the machine instructed to do the right thing?

  4. Did testers prove the outcome met expectations?

  5. Did the customer get what they wanted?

Put this way, would you even consider #1 without asking the customer for #5?

Developing complex systems is a team event, and there's no such thing as a simple system. Few disciplines call for near perfection, and we all make mistakes. Embrace and learn—find cause not blame.

If you are engaged in any capacity in a technology project, you have an important contribution to make.

How will you help?

If you've had anything to do with a technology initiative, circle your contribution below:

  1. Defining the outcomes—as simply as possible

  2. Theorizing how best to realize the outcomes

  3. Engineering the system's instructions

  4. Only shipping when the system meets the need

  5. Deciding whether customer need has been met

Now write:

  • What support did you provide to the rest of the team?

  • What support did you get in return?

  • What role did your customer have on the team? (Hint—were they involved in 1 and 5?)

How will you do things differently next time around?

... and if you missed these related articles, go back and take another look:

The 10x quality rule

Have you really solved the problem?

Of course your systems restrict innovation