|Mind / Matter|
By David Ness
Tuesday, February 12, 2002
This paper represents a collection of some of the important problems that we want to be able to solve as we deal with our collaboration.
Why Worry about Paradigm Problems?
Having a pocketful of Paradigm Problems is a useful thing when it comes time to try to design some packages of capabilities and services that might help us deal with some problem domain. In order to do design, we clearly must have some reasonable idea about what problems we are trying to solve. So it should come as no surprise that getting g clear about some of the problems is a necessity.
How do paradigm problems differ?
Paradigm problems differ from real problem in at least two important ways. First, the focus on the essence of the problem, not on the often distractive detail. One of the problems with teaching cases as a methodology for trying to improve student's problem solving capabilities was that students almost invariably wanted to dwell on the real aspect of the problems presented. All too often, however, the real detail of the case would involve all kinds of considerations that, while important in the particular situation, were not a part of any general lesson which could meaningfully be taught. The problems were real, but they had detail that diffused the focus on the core aspects of the problem.
Second, paradigm problems should be rich. If we form a collection of them they should span the greatest portion of the domain of the problem space. Taken collectively they should perform as an important test case for solutions that we propose. If we are able to solve this collection of problems, we should be reasonably confident that we have captured most of our understanding of the situation in our solution. While this can't guarantee that our solution is not naive, we can at least expect it to be no more naive than our current level of understanding. If our understanding is inadequate, we clearly have a problem, but it is at least not a design problem.
Problem 1: How's the Postman?
One simple problem already on the list is deciding if EMail connectivity is being maintained. It would seem that this should be a problem handled by those who maintain The Net, but one of the downsides of the distributed nature of the net (a good thing in its own right) is that responsibility is diffuse, and an EMail connection can fail for many reasons starting with problems in the sender's ISP and ending with the receiver's ISP, with lots of opportunities for outages in between. This leads to:
Paradigm Problem #1: I want to be able to evaluate the health of my EMail connection.
Problem 2: Managing EMail
EMail may come in from several different places. And sometimes we are on the road and need to be able to read it. And sometimes we read it in Netscape, Explorer, Opera, Eudora or something else. This leads to:
Paradigm Problem #2: I want to be able to manage EMail read by different programs and from different places.
Paul Graham's Principles of Design (in "Taste for Makers")
- Good design is simple
- Good design is timeless
- Good design solves the right problem
- Good design is suggestive
- Good design is often slightly funny
- Good design is hard
- Good design looks easy
- Good design uses symmetry
- Good design resembles nature
- Good design is redesign
- Good design can copy
- Good design is often strange
- Good design happens in chunks
- Good design is often daring
- Ness: Good design handles the next wider context
- Ness: Good design exploits time
David Ness' summary of work can be found at http://mywebpages.comcast.net/dness
Paradigm Problems are so called because they capture the essence of a problem without all of the extra complexity that so often obscures them in their natural occurrence.