That you write "I knew you'd have to come in with something irrelevant" only shows that you totally, 100%, missed the point.

"No coding should take place until the end-product is defined. It can't be defined until the hours, month, or centuries of research, among other things, are complete. "

But the project includes the research. And you do not know what the final product can be before you have done the research. And the research do include writing code.

What part of this is so hard to understand: THE RESEARCH IS OFTEN TO A BIG PART CODING!

Don't you get it? Research is building prototypes, and evaluate. Then build better prototypes and evaluate. And every prototype contains code. Hopefully as improved spins of the code from the previous prototype.

You did not get any ABS break system from people writing a complete documentation first. They just did not know what would be a suitable solution until they had made prototypes and tested. It's only the company that comes later and wants to duplicate the system that can write the documentation and full specifications before they start any coding.

"i think what you've written about reducing that board in size is complete nonsesne. If you know what the circuit does, how and when it does it, etc, then how big the board is makes little difference."
Yet more example how you sleep instead of think when you read the text. It's an example of a reengineering of a known solution. So the previous system can be seen as the full documentation - all that is needed is to "repackage" the solution in a better way. That is a situation where you don't really have any research, and can have all documentation up-front.

"then how big the board is makes little difference. If you haven't completely screwed up the hardware design, the requirements documents still apply, and coding can proceed once the hardware is specified. "
Since that was exactly what I did say - why was it so hard to then figure out that this was an example of reengineering where you do know all you need to accomplish beforehand?

Documentation is easy when you don't need research.

Documentation beforehand is not possible when you need research to even figure out how to implement something.

When implementing a compiler, the language standard is the major part of the documentation. And it exists before the compiler is written. So the extra documentation relates to implementation-specific behaviour, command-line switches etc.

When creating a new programming language, you don't get the documentation until after - you can't document until you know what the language will end up being. The majority of creating a new programming language is research. Testing what happens if going different routes etc.

Inventions just can not be documented before the invention have been made. Because if you do document it beforehand, then you must obviously already have made the invention to know what to document. So obviously impossible to do.

We have had this debate before - you just don't seem to be involved in any projects that does include inventions or research. And because of that, you just can not conceive that it exists.