I remember a few meetings similar to this, but where the issues weren't technical, but schedule. Some examples...
Meetings in which managers who would schedule invention by decree, "You have 6 weeks to invent an anti-gravity machine". Could not understand there was no way to estimate how long it would take to do something that had never been done before.
A meeting where development was behind schedule, so the manager arbitrarily start reducing length of remaining tasks until we were 'back on schedule'. At task level, task times were reduced by a hour here and day there, but the aggregate result was a success-based schedule in which every task in a complex schedule would have to be completed successfully in shortest possible time. In some cases tasks would have to be completed faster than had ever been done in company's long history. The manager shrugged off the risk. I'm sure he left the meeting satisfied that he had 'straightened out those lazy engineers'.
In a subsequent meeting with this same manager, after his 'shortest schedule' got behind, he arbitrarily started paralleling inherently serial tasks. "It's just software, no reason you can't start coding the interface before the API spec is written." That didn't work out so well either.
The weird thing is that these managers had engineering backgrounds, and should have known better, but they were 'old school' and didn't yet comprehend software engineering. Somehow, they thought that the scheduling principles that applied to building hardware could be circumvented for software.
