Somebody posted here recently about the a55-hole that should be fired, the senior guy who is negative and disagrees with everyone, the wet blanket.
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.
But we have to assume we'll overcome obstacles and not be crushed by them.
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.
I think this whole thing is purely an exercise in identifying obstacles. Identifying obstacles is a necessary first step in the process of determining whether or not you can overcome them.
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."
Relying on a company with enough slack to have senior engineers who can dedicate 6 months to a whim project and spare people to recruit in, seems not ideal.
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".
Message: any project would be cancelled if we knew ahead of time how hard its going to be.
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.
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.