The bizarre assumption of functional decomposition

I ran into a friend today and, as friends often do, we let our conversation wander over the different "broken things" in IT in general (and a few in Microsoft in specific).  One thing that I'd like to share from that conversation: a truly bizarre assumption that we teach, over and over, to new programmers... the assumption that simply following a "functional decomposition" process, a well-trained programmer will naturally end up with a good design.

Now, I'm no great expert on product design or graphic design or industrial design... but one thing I can say for certain: creating a good design is not the natural outcome of a simple process.  Only an excellent design process can produce excellent design.

Let me provide an example of good design from the world of products.  This picture is a picture of a footrest.  You read that right: a place to rest your feet.  Mundane, right? 

You tell me.  Does this product LOOK mundane to you?  How about the fact that it promotes movement and blood flow while serving it's primary function? (special call out to the design firm, humanscale, for creating this beautiful product.)

Design is not just a process of decomposing a problem into its constituent parts.  Nor is it a process of creating objects that contain functionality and data... yadda-yadda-yadda.  There are dozens of techniques.  Don't read my blog post as a slam on any one of them.  I'm slamming anyone who thinks that they should reach a conceptual architecture, derive one solution, and go... without considering alternatives.

Design is a process where you consider the problem and then propose multiple, competing, wildly creative solutions.  You then narrow down your brainstorm and weed out the bits that won't work... and then you propose multiple, competing, wildly creative refinements... and the cycle continues.  This happens a couple of times, until you have refined your solution by being creative, then logical, then creative, then... you get the picture.

When was the last time you were in a design review and the team being reviewed came in with multiple solutions, asking for help to narrow it down?  Really?

In no other field is the word 'design' so misused as it is in software development.

I have not met many folks that use a process whereby they design multiple, competing, wildly creative solutions in software and then evaluate them, select one or two, and go after the problem again at a finer level of abstraction. 

Not many folks at all.

Why is that?  We are living with the myth: that you can follow a simple process, produce a simple and "pretty good" solution architecture that represents a "good design".  No alternatives.  Very little creativity.

How's that working for ya?