Designing software is hard, and developers don't like doing it. All software projects start with an idea. Once you have that idea, either developed by yourself or imparted on you by management, it becomes time to start. There's a lot of requirements gathering and investigation that goes on first, but I'm not worried about that at the moment. Yes, the requirements often end up not matching what the software does, but that's a different issue. I'm concerned right now that the end result software usually doesn't even do (reliably) what the requirements document (or common understanding of the requirements) say that it does.
So you've got the requirements, and are now staring at a blank page. What next? Most developers I've encountered start writing code after spending some time thinking about how they want to handle things. There are probably some frameworks investigated, some high level design ideas sketched out, and maybe a few notes about architecture. Then the coding begins. After all, w're looking for something that works right? Make it work, clean it up later. It's easier to visualize what you are doing when you've got part of it up and running. Easier to add on functionality or move it around rather than create it from scratch. I suspect that in this "bootstrap" phase of design and coding is where a lot of the decisions that will affect the project far into the future end up being made.
Basically I think this is what Brooks was getting at with "build one to throw away." Building a system from scratch in the most obvious way possible can show you what the real usable abstractions are, and give a much clearer picture of what architecture should be chosen. But you have to throw it away for this to work. XP/Agile seems to gain its claimed efficiency basically by not throwing it away, but by vigorously reworking and improving it at every turn.
It doesn't change the fact that we don't like to design software, we like to write it. How many developers out there could create a complete technical specification for the implementation of a large hunk of code without anything more than language-indpendent pseudo-code, diagrams, and documentation? What format would that document even take, and what would it contain?
I'm skeptical that this is the right way to do things.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: