Complex Problems
Ayyasamy, Senthilkumar (UMKC-Student)
saq66 at umkc.edu
Thu Jan 9 03:24:20 CET 2003
> 4. Near-term vs. Long-term
>
> We have an established track record of being good at developing
> near-term solutions to near-term problems. Our success at solving
> large-scale/complex problems has been by creating a sequence of
> discrete, near-term solutions. It is the aggregation of such a
> sequence that creates the larger and longer-term effect. When we have
> tried to tackle large problems all at once and in their entirety, we
> have tended to take a long time -- and often thereby lose the market
> window, as well as the attention of the workers -- to create large,
> complicated solutions, and to have a very, very spotty adoption
> record.
I fail to understand your point. Lets take an ipng/ipv6, the most touted
long term problem. RFC 1550 is the initial solicitation draft for ipng.
If going by your method, how will you divide the ipng work into numerous
sub-problems? In theory, divide and conquer methods are easy. But, it will
be very difficult to split a complex problem at the *initial stage*. How
will you split without *defining* the problem? If you mean splitting
of long-term problem *after the initial problem defining process*, thats
what all WGs are doing ( atleast from what i have seen last one year.)
Time period is not an important factor. If the WG charter is vague, it is
difficult to finish even a near-term problem, as we cannot reach
consensus. So, defining a crisp problem statement is important
whether it is near/long term.
More information about the Problem-statement
mailing list