Then we get this - they should be praised, encouraged. I'm not so sure. Paralysis by Analysis used to be a popular phrase. Sure some kind of brainstorming of negatives is good. But we have to assume we'll overcome obstacles and not be crushed by them.
Back in the day I wanted to rewrite an OS to use a new memory model the i286 supported. I surveyed the code and presented the action list. Project never got off the ground - too much work.
Another senior Engineer took a different tack - he just started coding in his office. In 6 months he had recruited others to his effort, gotten funding, and completed the project. All because he didn't show people the obstacles, instead he promoted the advantages.
I think optimism is the reason we do anything.
There's a big difference between not letting knowledge of obstacles deter us and assuming we'll overcome them. The former is very important, for just the reasons you state. The latter effectively ensures that we will not overcome said obstacles, because we won't have effective plans to do so.
We have to assume we'll overcome obstacles, or we may as well all go home.
The second step would be analysis. It's pointless to identify obstacles just so you can assume that you'll overcome them all. Not all obstacles are created equal. You need to take the time to look at the more major ones in detail, so you can create a strategy, and then assess that strategy. The end result is more accurate assumptions.
Of course your best-laid plans may go to waste, and your best-made predictions may prove inaccurate. But to quote Dwight Eisenhower: "Plans are worthless. Planning is essential."
And the IT world is rife with unfinished, unsuccessful projects and people building themselves into corners. Your anecdote worked for your employer, but there are plenty of stories about "just started coding" leading to "big tangle of unmaintainable insecure slow messy code full o' bugs".
Just started coding - it was a mechanical process to vet every pointer usage for the new address space limitations. That example could be done that way.
>> Klein’s proposal, which he calls the “premortem,” is simple: When the organization has almost come to an important decision but hasn’t committed itself, it should gather a group of people knowledgeable about the decision to listen to a brief speech: “Imagine that we are a year into the future. We implemented the plan as it now exists. The outcome has been a disaster. Please take 5 to 10 minutes to write a brief history of that disaster.” As a team converges on a decision, public doubts about the wisdom of the planned move are gradually suppressed and eventually come to be treated as evidence of flawed loyalty. The suppression of doubt contributes to overconfidence in a group where only supporters of the decision have a voice. The main virtue of the premortem is that it legitimizes doubts. Furthermore, it encourages even supporters of the decision to search for possible threats not considered earlier. The premortem isn’t a panacea and doesn’t provide complete protection against nasty surprises, but it goes some way toward reducing the damage of plans that are subject to the biases of uncritical optimism.