Had a number of comments back to my earlier post asking whether software design was art or science. From the sampling, which was highly self selecting & amongst a number of old friends/acquaintances, there was an overwhelming sentiment that software design is unequivocably art. I also had some more time to think about this stuff, having been very busy with the team in Detroit. Good trip, great getting to meet and spend some time with new associates from OpenText. Also, very glad to be back home!
A strong proponent of good design being analogous to art and art-minded people (well, right-brained anyhow). An interesting observation by Frederick Brooks in “The Design of Design” “the Waterfall Model is wrong and harmful; we must outgrow it.” Like art, design is a non-sequential process that, when done well, requires significant iteration and successive discovery. At the risk of turning this into a book report (I’m liking his book, by the way), he also makes reference to a term he’s coined “conceptual integrity” which refers to a design following a theme/pattern/or message. While these sorts of things can be born out of science and/or nature, they tend to permeate the world of art. (another very weak argument that design is art).
I’m pretty squarely on the side of art, but an art that somehow needs to be harnessed. The discipline of design, and in many cases, maintenance is a craft (art) in which I’ve observed massive variance in people’s abilities and throughputs, even when there’s evidence (similar educational backgrounds, experience) that would point to some inherent aspects that relate to individual’s right side of their brain and abilities to visualize and conceive of valuable creations, much like art.
The big dilemma (for me anyhow, and I’m sure many folks), is that even though this has the qualities of art, there’s an economic imperative to somehow turn it into a predictable science. Herd some cats, anyone?
Managing as Little as Necessary 
It’s an enduring and classic question, isn’t it? Great software starts with passion and creativity, which must then be channeled through the discipline of software engineering. An architect, through a soaring imagination, can imagine a wondrous new type of bridge — the beautiful lines and soaring spans, for instance — but must then sit down to the engineering task of building it to be safe, meet budget, timelines etc.
As for software, I’m with Brooks on the conceptual integrity thing. For me as an architect, one of the most important aspects of a successful software project is that it hang together conceptually. If you’re interested, I put some thoughts down on it at http://softwarekeith.com/2010/12/21/conceptual-coherence-in-software-design/…
Thanks for the pointer. I’m finding myself having to tackle these problems from all sides. On the construction/structure side, I’ve long since recognized that I (and my team) is toast absent the innovation and insight that comes from the level of awareness and creativity that pops out of the right side of the brain.
At the same time, I’ve long since realized that you still have to get things done, and get them done well. That requires the perspiration side of the equation. Absent both, not much interesting (or useful) seems to happen.