A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I like the distinction made elsewhere in this forum between limitations of resource (usually time and money) and requirements of function (doesn't blow over but is easy to lift, is big enough that it doesn't overflow but doesn't obstruct the sidewalk, etc). Perhaps a third category is the constraint of precedent.
Precedent has a huge effect on design, particularly in my little world of software design. Just take a look at Raymond Chen's "The Old New Thing" blog ( http://blogs.msdn.com/oldnewthing ) to get a sense of how often we need to design with precedent in mind.
Of course, it also impacts the design of physical objects. Consider our humble trashcan example: presume they want to make their trashcan easy to maintain by using liner bags. Now you are constrained to the precedent of all the trashcans that came before you, the sizes of which have in turn determined the sizes of commoditized trashcan liner bags. Unless your client doesn't mind manufacturing their own six-foot-long, two-foot-wide, one-foot-deep liner bags, you'd best not design a six-foot-long, two-foot-wide, one-foot-deep trashcan.
At the risk of broadening the topic too much, I would add that while requirements may be constraints, people's perceptions of what the "real" requirements ARE becomes an endless source of argument. The line between "If this is what you want" and "this is how we have to do it" is traced very differently by different people.
I design relational databases. Silly me, I like them to be 3rd normal form. Partly because I was trained to do things "by the book" and because I learned there is hell to pay when we don't. Yes, Joel, there are trade-offs that might be entertained, but the cost **to those who understand and appreciate it** is way too high. The un-initiated will not see some components of your "good design" as necessary, until the problem surfaces that it was **designed** to avoid.
I have coined a phrase which I call the Pancreas Principle. A good design often has components in it that ARE required but that some, in their ignorance, will not be able to understand. Don't let them rip them out, they are there for a reason.
There is something very strange in how we classify software, that is how we say that this is a email application and that is an instant messanger, and how users use that positioning and analogies with other specimen of that particular category to understand what the sofware does.
This is different from how we name our phisical tools because the phisical design has many more constraints. A hammer that is also a screw driver will never be usefull, but a text editor with built in FTP client is. The only analogy I can find from the past is the concept of genre in literature.
Saturday, January 28, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz