I think that might be paraphrasing implications of Gödel's Incompleteness Theorem.
Non-trivial codes can either be consistent or complete, but not both (within a system of abstraction).
This explains Joel's "Leaky Abstractions" essay as well as the conjecture that code cannot be perfect.
However, "good enough" thinking is often just sloppy thinking. Even if mathematics has boundaries, it doesn't mean you just shrug and say "a nod is as good as a wink".
Craftsmanship and quality are perceived in terms of utility over time. "Good enough" often doesn't meet that bar.
Engineers overbuild to support capacity and plan for the worst. "Good enough" tends to under-build at or below capacity and hope for the best.
"Good enough" is a just reaction to over-engineering (the adding of unnecessary fixtures and 'perfection'), so the warning has value and there are some engineers who use it in this way.
But others often mistake over-building for over-engineering and cripple their organizations and products by seeking "good enough".
Non-trivial codes can either be consistent or complete, but not both (within a system of abstraction).
This explains Joel's "Leaky Abstractions" essay as well as the conjecture that code cannot be perfect.
However, "good enough" thinking is often just sloppy thinking. Even if mathematics has boundaries, it doesn't mean you just shrug and say "a nod is as good as a wink".
Craftsmanship and quality are perceived in terms of utility over time. "Good enough" often doesn't meet that bar.
Engineers overbuild to support capacity and plan for the worst. "Good enough" tends to under-build at or below capacity and hope for the best.
"Good enough" is a just reaction to over-engineering (the adding of unnecessary fixtures and 'perfection'), so the warning has value and there are some engineers who use it in this way.
But others often mistake over-building for over-engineering and cripple their organizations and products by seeking "good enough".