More rigor does not mean more process, more process does not mean more rigor

I got really pumped up to die on this hill (again) today, but managed to back off at the last minute. It might be aerospace or technology esoteric, it might not be—I don't know.

"More rigor" does mean "more process". And "more process" does not mean "more rigor".

I worked ever-so-briefly in a software quality assurance organization with some respectable and respected engineers. Here's what happens when you value—abstractly value—process: you get more process. My analogy for it was always something like this. What does Lebron James get paid for? Making more baskets. What do process engineers get paid for? Making more processes.

Not bettermore.

More process works for a while—until it doesn't. There's a sort of inverted-U of usefulness. There's Wild West on the left side where you're just slappin' things together—great for the garage and the protoshops, less so if you want build things that people use, especially to put themselves in at tremendous speeds and altitudes. There's total lockdown on the right side where you don't move don't think don't breathe don't achieve [1].

The sweet spot is there in the middle somewhere. It's never a stable optimal point—the people change, the technologies change, the requirements change, the certification authorities change, your understanding of the problem will change, and so on. But the answer is not more unless you're flat-out missing things. In fact, as you add more, you are at some point begging for steps to be missed or mangled, for process steps to fall behind reality, for malicious compliance out of frustration.


[1] Too much is not enough / I feel numb

Leave a Reply

Your email address will not be published.