This isn't really true for all software development. If you write a detailed design, the process for writing the software is as simple as "write what the design says you should write, then test it conforms" It's only true for the sort of software development where you design while you write, AKA hacking.
I'm not against hacking per se. I'm doing it right now. But to take it as the de facto way the software industry functions is wrong. Hacking has certain problems, like unanticipated problems tend to stall the process (My own recent encounter had me blocked for three days, trying to think of an adequate solution to the problem of how authentication should work in an environment where HTTP servers and clients are essentially "decoupled", that is a solution to the problem of where presentation and application data are coming from two different sources, how does the data provider verify the presentation logic is trustworthy? It's a hard problem to which I have only a partially satisfactory answer... but I digress.)
The process for writing code tends to be unwritten, simply because in the best case it is so trivial that writing it is an insult to the reader. I guess the industry's collective problem is that the best case happens so seldom.
<i>It's a hard problem to which I have only a partially satisfactory answer... but I digress.</i>
On the contrary, you touch the heart of the matter. You say what you are doing is "hacking", with the implication that there exists some other process by which your problem could be solved. Can you tell me what this process is, and why you are not following it?
You’re making a basic assumption that your design has sufficient detail to produce the program. The problem with this idea is your moving programming to the design phase (using pseudo code) but you’re not eliminating the act of programming.
AKA, I need a function called add that adds each element in an array and returns the result.
Now what data type is in that array? What should you return if the array is empty or null? etc.
I'm not against hacking per se. I'm doing it right now. But to take it as the de facto way the software industry functions is wrong. Hacking has certain problems, like unanticipated problems tend to stall the process (My own recent encounter had me blocked for three days, trying to think of an adequate solution to the problem of how authentication should work in an environment where HTTP servers and clients are essentially "decoupled", that is a solution to the problem of where presentation and application data are coming from two different sources, how does the data provider verify the presentation logic is trustworthy? It's a hard problem to which I have only a partially satisfactory answer... but I digress.)
The process for writing code tends to be unwritten, simply because in the best case it is so trivial that writing it is an insult to the reader. I guess the industry's collective problem is that the best case happens so seldom.