You can't find me wrong about something I haven't said. Or wait a minute. Yes, Richard - you can. But then, you are living in a different world. You are screening every line of text you read based on a calendar year if 1970. Which means that you regularly have to fill in the blanks when a concept doesn't fit the current knowledge in existence 1970.

Next thing: For some reason it seems to be 100% impossible for you to realize that research often does require coding. You can't sit and look at a wall and do real-life research. There are experiments. There are prototypes. There are evaluations.

Research normally includes lots, and lots of coding.

It may include things like: "what will the CPU load be for software-only tone detection of DTMF tones?" Or "what is highest baudrate for a software-only modem on this processor". All because the answer to the above tells if it will be cheaper with a sw-only solution or with dedicated hardware outside. And the above is still a trivial case since the research part is only about consumed resources - not about actual behaviour.

In many situations, the full problem is too complex to solve perfectly. So the task is to find what is good enough. Which stimuli can be ignored? Which stimuli can be approximated? Which stimuli must be measured with high precision or at high speed, and which stimuli can be sampled very seldom? Which stimuli must take precedence? What will be the end result if predication is used? So prototypes are built. Prototypes containing real code. And with good software engineering, that code will be modified multiple times until the total hw/sw design can be shown to solve the problem. At which case the project do not throw away the code, spends months writing a full design document, and then starts coding from scratch. For some reason, companies wants to make money - the main goal is not to employ software developers.

No, Richard. There is no way you can convince me for the simple reason that I would not be allowed to create a full design document based on fantasies (it will be fantasies if not backed by practical tests by me or someone else) and then force someone to write a complete program based exactly on that design and then ship it. Unless possibly the goal is to make a lamp timer, in which case the problem to solve is trivial - there are no research other than to find good components. It's only an engineering task to solve a fixed problem resulting in a competitive product. But then I would probably not be involved - western companies can't compete with this kind of products.

I just never do projects where the goal is to duplicate the exact behavior of an existing product - potentially after one of the components have gone off the market. Companies don't want to duplicate old products - they want products that separates them from their competitors. It's basically the users of a product who might want a replacement copy. The rest of the world wants to figure out what progress there can be, based on advances in other areas.

In the end, the feasibility study at the start of a project normally do contain coding, because no other engineering methods can show something feasible. Especially when feasible includes cost as an important term. It's irrelevant if code can be written for a specific task, if the hardware will be too expensive.

In the end, documentation must be interwoven with coding. There can't be any coding only after the documentation is written expect for trivial projects. You can't just sit down and write a complete design specification for the main electronics controller of a car. You might be able to copy a previous design, but then you obviously have made use of the results from previous coding. In the end, it's all about complexities. We can't document what we don't understand. And to understand, we need prototyping and testing.

Next thing is that many projects are so large, that they aren't economical/practical to perform as a single step. So the project is splitted into many spins. And these spins can't even be fully described either, because some part of the spin is based on roadmap and some parts are based on ongoing feedback from users/testers of previous spins.

You write a subject "It's not about me ... it's about process". But then you still seem to miss that it really is about process. Take a closer at real-life processes. Doesn't matter if it's programming, customer relations, chemistry or something else. Processes normally contains feedback loops. They have iterative patterns, for the simple reason that most processes don't have access to enough input information and a complex enough computation engine to go directly to a final result.

Real-life problems have flowcharts where each box requires a flowchart - and that flowchart will probably also need flowcharts to represent the individual boxes. But then, Richard - please tell us any big, commercial, company that don't make prototypes. After all - prototypes aren't needed if everything can be documented before the first code line is written. That must obviously translate the same for the electronics, mechanics, ... in the product. In a real world, the people who don't need prototypes are the ones who just duplicate someone elses product.