Doing It The Right Way

In school, I learned that good engineering can be done once but to consistently build things well, you need to write down the process you are following, and then repeat that process each time.

Of course, the process isn’t perfect so you add another layer and, whenever you screw up, you go back to that written process, figure out what you should do different so you don’t make the same screw up the next time, and write down this new, revised process.

The assumption is that by doing this over and over, eventually you’ll have a perfect process. And by then carefully following that process, you’ll build perfect products.

But, of course, it doesn’t work that way.

While the logic is irrefutable and, overall, it’s a really good way to go, you learn that “the process” doesn’t always work. It doesn’t always work because we’re human. We make mistakes. We delude ourselves. We deceive others. We get lazy. We lose faith. … And so on.

But, because we are human and likely to mess up from time to time, does that mean this iterative process of “follow the written steps, and fix the steps that are broken, and follow them again” – do we throw out that whole idea and just start from scratch each time?

Of course not.

Most of the time, humans can successfully follow instructions. If they’re written down, all the better to avoid mis-interpretation and compensate for creeping forgetfulness.

But humans will still fail and so that’s why in important things we always ask someone else to “have a look.” This is called “due diligence” and it means that even when someone says they followed the process, you still have someone check the work to see if they really did.

The process that gets developed will, invariably, have testing steps, and those tests will – the process will state – be done by someone other than the original developer.

With really important things like airplanes and rockets, there will be two different groups, the builders and the testers. One group builds, the other group tests. They both look at the same design specification but each then independently figures out what that means. If the two groups come up with radically different interpretations, that’s going to show in the test group’s report, and it means that the original design – the written design – is flawed and needs to be fixed.

Over all my career, if I had to say one thing is more important than anything else, this would be it.

1. Write down your process.
2. Follow your written process.
3. When something goes wrong, re-write your process so it can’t happen again.

If you’re doing something important such as teaching engineers who are going to be building rockets, airplanes, automobiles, robotic surgical systems, network infrastructure and any of the other thousands of computer-based gizmos that govern and increasingly protect our lives and you’re not doing this process, then you’re doing it wrong.

This applies to teaching engineers as much as it does to what those engineers are doing. If you teach them wrong, they are going to design it wrong.

Doing it any other way is unprofessional and, worse, irresponsible.

And someone is going to get hurt.