Earlier quoted context omitted.
In my experience translating requirements into a formal language (programming language) is where a lot of the important details are actually worked out. The process of taking the "squishy" thoughts/ideas and translating them into code is a forcing function for actually clarifying and correcting those ideas.
In PRIDE, the important details are worked out before the first line of code is written, in the form of flowcharts and other technical documentation. The earlier in the design and development cycle this is done, the less work you have to do over the entire SDLC and the more time/effort/money you'll save. Bryce: "Mental laziness can also be found in planning and documenting software. Instead of carefully thinking thro…
IMO writing code isn't really more laborious than writing flowcharts and docs. I typically write code to explore the problem, and iterate until I have a good design.
What you're describing is more or less the waterfall model, which has its advantages, but also drawbacks. I don't see anything reason to treat code as only a final implementation step. It can also be a useful tool to aid in thinking and design.
> The earlier in the design and development cycle this is done, the less work you have to do over the entire SDLC and the more time/effort/money you'll save.
I believe this is only true if you treat the first code you write as the final implementation. Of course that's going to cause problems.