How many times do we assume something from incomplete or inconsistent input, and end up running off in the wrong direction, wasting time or money, our own or someone else's?



Getting the facts straight in the beginning is the real lesson to be learned from this particular "logic problem".


Back in engineering school, almost every class in the core curriculum began with a review of the basic problem solving method. For some classes, there were 8 steps, for others 5. But they were all variations on a theme. They were all variations of the basic four-step method outlined by the hungarian mathematician George Polya in his book "How to Solve it."
(Details at http://makeashorterlink.com/?Q33D12536)

Step 1. Define the problem.
Step 2. Plan a solution.
Step 3. Carry out the plan.
Step 4. Look back (check the answer).
Summary of method outlined in "How to Solve it," 2nd ed., 1957.

(In statics or dynamics courses, there is, among other things, the additional step of drawing a diagram, for example. But this is just a refinement to step 1, above.)

One of the most common and important reasons for projects to fail is the failure of the engineer to commit to step 1. It's a difficult thing to do when the culture says "get things DONE" to waste time sitting back to reflect on what exactly it is that one has to get done.

Dewey has essentially the same idea with the first "step" being the recognition that a problem exists.
From http://makeashorterlink.com/?V32D25536
"Upon examination, each instance reveals, more or less clearly, five logically distinct steps: (i) a felt difficulty; (ii) its location and definition; (iii) suggestion of possible solution; (iv) development by reasoning of the bearings of the suggestion; (v) further observation and experiment leading to its acceptance or rejection; that is, the conclusion of belief or disbelief."
"How we Think," 1910

Stated so clearly, one can only marvel that so many projects fail in this regard. I think there are several reasons: 1) economically, projects are pushed to show results and 2) psychologically, engineers like to show results.

In any case, all of this is just to reiterate that I agree with your point.

k