Software Design Responsibility
Being a public holiday today, I spent the morning lazing in bed and ended up re-reading most of Chris Crawford's book, On Game Design. It's a fun read from somebody who has both experience and opinions.
It also contains a passage that stuck with me the first time I read it and has guided a lot of my design thinking since then (from chapter 18):
"Some people think that open mindedness requires a deisgner to hear out every idea, to give every suggestion its day in court. This isn't noble; it's stupid. Seriously considering every idea that drifts by isn't a sign of open mindedness; it's an indicator of indecisivness. A good designer has already thought through all the basics of the design and so should be able to reject a great many ideas without much consideration, To put it another way, you should already have considered most of the ideas that are put to you; if somebody surprises you with an idea you didn't think of, you should consider it a warning sign that you haven't thought through the design carefully enough. If the rgeat majority of ideas that are offered you have already gone through your mill, you should have no problem rejecting them without much consideration. Other people will consider you a narrow-minded prima donna for doing so; let them. Your job is to build a great design, not gratify your co-worker. Be courteous, but concentrate on doing your job."
I'm not in 100% agreement with this as it applies to Open Source development. There are many areas in a project where the primary developers and designers mentaly or explicitly mark an area as "we'll work that out later" or "to be revisited when we have time". Design discussions in those areas are often fruitful and enightening to everybody.
In many areas, though, the main designers usually have thought through a lot of the decisions and have developed an intuition about what works, what won't and what direction they want to head in. I do think this sort of approach to open mindedness is only applicable for reasonably well established designs by developers with a certain track record of success. Something in the early stages of development or being as a first project should welcome holistic reassessment.
It is not incumbent upon a software package maintainer, even in Open Source circles, to continually revisit and rejustify every decision whenever somebody new wants to challenge a particular case. That is ineffective.
When reading through source code, you can often work out, without too much difficulty, the design thread running through various decisions. Initially, accept that as gospel. Later, as you become more familiar, look for areas of inconsistency. Does the inconsistency matter? Can it be reconciled? Is it actually a cause for problems? True sharp edges or ill-fitting pieces exist in most applications. Sometimes it's best to just acknowledge they are there and move on. Sometimes, you can smooth them off with a bit of a rewrite, although this may force some changes on the users, too. Often, the number of inconsistencies are not as great as people might think. Any number of alternative solutions may not be implemented or even explored in great detail; because they do not need to be. Once you have one solution that fits your design approach succesfully, it's usually pragmatic to move on. Iterative improvements will still be made, but radical design changes aren't as necessary as some people would like to believe.
Finally, the closing sentence in the above quote is an important responsibility for the designer:being polite never killed anybody. Soliciting suggestions, even though you may have already implicitly considered many of them already is a tricky task. You need the haystack, for it contains the one needle that fixes an important problem. Encourage contributors, but ask them to have realistic expectations, too.
Postscript: I probably didn't make it clear why this quote from Crawford has influenced my thinking. It caused me to think.. Because I don't completely agree with it, yet can see some elements of wisdom there, it has made me think a lot about when design discussion are useful and when a project design leader should cut off the discussions and pick a path.
Second postscript: Turns out I've blogged about this quote before (see October 25 and 27 entries on that page).