The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

design constraints != solutions

The example with the trash can conflates design constraints (or requirements) with solutions.

The trash can has to make it easy to collect the trash.  That's a requirement.  Making it light is one way to achieve that requirement, but not the only one.  Perhaps a lever mechanism can make even the heaviest can easy to empty into the garbage truck.

The trash can shouldn't blow away in a strong wind (requirement).  Being heavy is one possible solution.  Reducing the can's cross section, perhaps by using an open lattice exterior, is another.

Thus the design constraints are necessarily contradictory, only the solutions proposed.  In my mind, the hardest thing about design is not making trade-offs, it's getting very clear on the requirements.
Adrian McCarthy Send private email
Friday, January 27, 2006
 
 
Yeah, something struck me about that article and you've hit it on the head.

For example, a bin could be bolted to the ground (to prevent blowing away) but have an inner liner which is removable (to simplify collection).

That meets the requirements yet isn't contradictory.
KC Send private email
Friday, January 27, 2006
 
 
In my humble opinion, you two are being overly critical and are missing the point.  The point is, you can't have everything you want, so you need a formula/method to help you get as close to 'everything' as possible.  Joel's illustration makes the point very well if you accept it for what it is, rather than assume that somebody has really hired him to design a garbage can.

Besides, putting a liner in a public garbage can is a terrible idea.  Either the maintenance crew is bound to have an off week and run out of liners or somebody will put their old cactus into that thing and rip a whole right through it so that cactus dirt and somebody else's discarded Pepsi go running into the bottom.  Then, since it's bolted to the ground, some poor garbage engineer will have nightmares for life, reliving how he/she had to climb into that pit-of-dispair and clean it out.
Central Cal Girl Send private email
Friday, January 27, 2006
 
 
"Joel's illustration makes the point very well if you accept it for what it is, rather than assume that somebody has really hired him to design a garbage can."


I think Joel demonstrated very clearly how easy it is to jump from "Requirements" to "Solutions" without even thinking about it.

When someone says "it has to be heavy, but it also has to be light", you need to dig deeper for the underlying Requirements being addressed instead of getting tied up in one person's solutions.
KC Send private email
Friday, January 27, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz