This is just a case of poor communication, people talking past each other. There's a big difference between the following two questions:
1. Can the proposed idea be implemented as stated?
2. Does the proposed idea degrade gracefully, i.e., will an imperfectly achieved solution provide significant benefit?
The answer to #1 is almost always "No" because the simplest way to state an idea, the normal way to refer to an idea in conversation, implies that it will work perfectly in all cases. For instance, "bug free software" is impossible in practice, but if you achieve nearly bug free software, you'll have much less buggy software than your competitors.
You can't talk sensibly about any idea without explicitly moving on to question #2 and talking about costs versus benefits. Will one bad data point in the Shop Control Application cause an accident that costs ten times as much as the efficiency gained? Will the value of "bug free software" be negated by a single bug in a release? If your boss is still talking in absolute terms about question #1, then you need to move him to question #2 by explicitly talking about what the benefits of an imperfect solution are. In your mind, it may be obviously implicit in your proposal that there will be cracks in the system, but you can't blame your boss for taking your proposal for "bug free software" literally unless you explicitly address how an imperfect solution will be useful.
To the contrary, with adequate rigor it can be done. Naysayer complaints of "that takes too long" forget that there is no subsequent time spent fixing bugs because there aren't any.
Using formal methods, the only place where you have near-perfect assurance of no bugs is between the spec and the code. You can't have a bug-free spec without bug-free requirements gathering and bug-free documentation. You can't have those without bug-free natural language communication. Also, a reasonable spec for a complicated piece of software is itself a complicated piece of code. If you can prove the spec is accurate by checking it against a smaller spec, and that spec against a smaller one, until you've reduced a problem of arbitrary size (say, the Eclipse project?) down to a reasonably human-checkable spec, then you run into complexity barriers. How is it possible to rigorously specify something as complex as Chrome or Microsoft Excel in a spec compact enough that you can certify it is error-free?
How is it possible to index the entire Internet's content, and perform nontrivial searches fast enough that a page of hits can be rendered as the searcher types? That may work on a small scale, but scaling up you run into complexity barriers. It's impossible in practice.
Oh, right, Google did it.
Your reasoning is exactly what the article criticizes: the notion of "that's impossible, don't bother" vs. "so what, let's do it anyway".
Our ability to handle complexity scales exponentially over time, and we're on a fast-rising part of the curve now; even if something is "impossible in practice" now, get started on the problem and predict at what point the industry _will_ have the technology to handle that level of complexity.
Hard != impossible.
Hard now != hard in the relevant future.
1. Can the proposed idea be implemented as stated?
2. Does the proposed idea degrade gracefully, i.e., will an imperfectly achieved solution provide significant benefit?
The answer to #1 is almost always "No" because the simplest way to state an idea, the normal way to refer to an idea in conversation, implies that it will work perfectly in all cases. For instance, "bug free software" is impossible in practice, but if you achieve nearly bug free software, you'll have much less buggy software than your competitors.
You can't talk sensibly about any idea without explicitly moving on to question #2 and talking about costs versus benefits. Will one bad data point in the Shop Control Application cause an accident that costs ten times as much as the efficiency gained? Will the value of "bug free software" be negated by a single bug in a release? If your boss is still talking in absolute terms about question #1, then you need to move him to question #2 by explicitly talking about what the benefits of an imperfect solution are. In your mind, it may be obviously implicit in your proposal that there will be cracks in the system, but you can't blame your boss for taking your proposal for "bug free software" literally unless you explicitly address how an imperfect solution will be useful.