Nor do these sorts understand that you can't put a schedule on "research and development."
sure you can - and you have to.

I have seen product developments "without a schedule" going south because every darn detail was overdone to such extermes that the programmer productivity ratio was about 10%. If you can write an efficient piece of code in one week, it takes months to write the same to "superoptimum". All code should be efficient and there should be no cutting corners on the design regrding functionality, but, in most cases, that last 10% efficiency is just too expensive. If your volume is so that you need that last 10%, hire more people and then schedule by the numbers such an approach require.

I have seen product developments going south because they were schecduled by "we need the product by" method and came out with so many open issues that the result was horrible (note the results from those that publish release dates a year in advance).

I have seen product developments going very well beacuse they were done to a reasonable schedule. When a schedule is well made, you will find that every step is either ahead or behind, but the total comes in just as planned.

As an actual example, I have seen a programmer spend weeks on optimizing a routine in a product of which the plan was to make 5 (too lose a scedule). I have also seen a programmer work on the "C is C" paradigm on a product where 500.000 were to be made (too tight a schedule).

Erik