Converse Errors reminded me of math analysis, necessary and sufficient conditions proving a conjecture. In the field of Control Theory, which is what I studied, I remember seeing more proofs around linear time-invariant systems employing both necessary and sufficient conditions. Proofs around nonlinear systems, however, that could muster more than just sufficient conditions were nonexistent. My peers and I always related that observation back to how much better we were able to design controllers in the context of the former. The toolbox was just bigger. Which is likely why my favorite professor used to say “the best Control Engineers design their Plants” (i.e. the system to be controlled, versus the controller, which is what we trained on designing)
Necessity and sufficiency are exactly the right analog. (I love the connection to control theory.) It’s a useful way of thinking in software engineering as well, to distinguish between the two types of conditions that is—good usability implies a positive user experience, but a positive user experience needs other things to be true as well (correctness, other quality attributes); good documentation implies maintainable code, but maintainable code needs other things to be true as well (high code coverage, high cohesion, low coupling, low code smells).
Converse Errors reminded me of math analysis, necessary and sufficient conditions proving a conjecture. In the field of Control Theory, which is what I studied, I remember seeing more proofs around linear time-invariant systems employing both necessary and sufficient conditions. Proofs around nonlinear systems, however, that could muster more than just sufficient conditions were nonexistent. My peers and I always related that observation back to how much better we were able to design controllers in the context of the former. The toolbox was just bigger. Which is likely why my favorite professor used to say “the best Control Engineers design their Plants” (i.e. the system to be controlled, versus the controller, which is what we trained on designing)
Necessity and sufficiency are exactly the right analog. (I love the connection to control theory.) It’s a useful way of thinking in software engineering as well, to distinguish between the two types of conditions that is—good usability implies a positive user experience, but a positive user experience needs other things to be true as well (correctness, other quality attributes); good documentation implies maintainable code, but maintainable code needs other things to be true as well (high code coverage, high cohesion, low coupling, low code smells).