Self-Tolerance For A Zero “Test” Engineering World
Once upon a time, I sat in a big hall filled with other “heads” that were about the size of mine; we were all looking in the same direction for some unknown reason. Wait… I know the reason! We were all watching a tall and grey head telling us how to be “good” engineers. As it turned out, he was actually effecting the exact opposite : he was teaching us everything wrong about engineering design!
“Test” Engineering
Test-reliant engineering is a discipline that owes itself to the empirical sciences and the scientific method. The basic idea being that for one to “prove” that their hypothesis is true, they must provide “evidence” for their hypothesis. No hypothesis therefore, that is unproven, is to be trusted.
When any new system or product is being designed, it is essential for the designer (and his team) to NOT become too overconfident with his “initial” design. He must assume, for all intents and purposes, that HIS design will always be incorrect UNTIL it has been fully manufactured and used by the consumer.
There then arose the perception that if (essentially) nothing is true until it is “proven”, then anything built, that has not been proven, is simultaneously suspect.
I call this “test”-engineering in a sense that the process assumes “testing” should happen after the design and a build have been packaged. (It is immaterial at this point to ask whether a “build” is done “earlier” at the unit-level or on the first and smallest version of an engineering product.)
Manufacturing IS THE BEAST
The problem with these normalised approaches to engineering design is that they lack a robust “manufacturing” outlook. Manufacturing is usually approached with an eye of either “this is to be done later”, or “that’s for the production guys”. Either way, it is a very inconsistent approach. It is also a very defective approach in the sense that it refuses to look at the FINAL END of why a product is being designed in the first place. If manufacturing is likely to affect the “outcome”, then, surely Manufacturing IS Design!
Part of the problem then, with attempting to “change” the process that most engineers follow when performing an engineering task, is that the thinking is INCORRECT. Many engineers naturally assume that “team roles” matter more to the engineering process, than the “team OUTPUT”. (The assumption is that better “role-playing” means better management. It is then assumed that with better management, better results can be achieved.)
The way to process my thesis then, is to ASSUME that I strongly believe that Design is Not Completed, Until Manufacturing/Production is Completed.
Without this assumption, it WILL be far from possible to comprehend the argument I am about to make…
Self-Tolerance
When any new system or product is being designed, it is essential for the designer (and his team) to NOT become too overconfident with his “initial” design. He must assume, for all intents and purposes, that HIS design will always be incorrect UNTIL it has been fully manufactured and used by the consumer.
The challenge then, is figuring out the relationship between the “what the team is doing before product release” and “what the team does to AVOID a bad release”.
IF what the team is DOING before the release is (always) WRONG, then how is the team going to “produce” the RIGHT thing? (Some hacks that have been proposed such as “agile”, and “iterative design” are NOT altogether helpful).
If one uses the “traditional” waterfall approach, then the team can at least be assured that they will always be confident of what they are doing. But confidence, does not equate to competence.
Kanban/Lean, is truly the most effective manufacturing process precisely due to the fact that it addresses this particular challenge extremely well. In Kanban, the design is ONLY completed when the manufacturing OUTPUT has no flaws.
It is no wonder that MANY “process-engineers” confuse Lean with Agile!!!
But Kanban has a meta-design problem. It doesn’t address issues with regards to what exactly should be done when a “flaw” is detected. It is no wonder that MANY “process-engineers” confuse Lean with Agile!!! Lean is NOT Agile. Lean is obviously about “how to produce X adaptively” with the least amount of inventory and time. Agile is about “how to adapt while producing ‘God knows what will come out’”. Lean is definitive but adaptive in its applied mechanics. Agile is adaptive but decidedly non-definitive. Lean doesn’t need Agile to work. Agile needs Lean to work.
Kanban has a meta-design problem.
The Kanban meta-design problem can be EASILY resolved via the concept of Self-Tolerance.
Self-tolerance is about prioritizing what the DESIGN should not do as opposed to what it should do during a design project. It is the page “404 page not found” design FIRST approach.
Lean Self-Tolerant DESIGN
Naturally, not every “design fault” on the planet can be incorporated into one product.
But that is NOT what “self-tolerant” design is about. Self-tolerance is about what happens if “Function B” doesn’t work. It is the Lean/Kanban relative of “listing” only what is necessary to achieve a particular OUTPUT.
Instead of “building” then “testing”, a design will need to be in “testing”-while-“working”. The “Self-tolerant” design program then, should design not merely for “test-cases” but should deliberately make system/product “parts” that deal with system/product faults.
These faults would then need to report to the system first, the operations/sales/production team second, and the engineer last. The customer may never be allowed to experience or see them!
The problem : the product/system engineer MUST be the one to incorporate these (above) ‘tolerance’ (technical+business) parts into the product itself. But engineers are not used to thinking like this! We usually want to “make” things “that work!”, and to prove that they DO indeed work; “testing” gives us a fairly straightforward way to “prove” things, and run-away after that! But this is NOT the way to do it if the engineer cares about the end-user. The user cares “very little” about whether “testing” was done before a website launch. The site must simply work. UNDER every single instance! It is in the engineer’s best interest then, to NOT even consider “testing” as something critical when engineering a product. Accidentally, the user still cares little regarding whether the engineering team is using “Agile” to iteratively test the product. The product, must SIMPLY… never fail!
Some Implications, and Clarifications
The more “specific” the design goal, the easier it is for the engineer to think in terms of “self-tolerant” design than “testing”-based design.
This simply means that if the engineer is not willing to LET his design be proven INCORRECT or wrong, he is NOT doing a good job. But for the engineer to be willing to be proven wrong, he must also be willing to set the clearest terms for the falsification of his design. The clearer his terms, the easier it is to build a self-tolerant system.
Final Remarks
Just as the “scientific” (demarcation) method led the engineering world to conclude that “building” then “testing” will yield to us good engineering products; we should allow the “falsification” (demarcation) method to guide engineering even further.
We can never truly prove “goodness”!
But we can easily prove when something doesn’t work! But even that, shouldn’t let us engineer things that have the smallest chance of not working.
