[
Lists Home |
Date Index |
Thread Index
]
igraham@ic-unix.ic.utoronto.ca (Ian Graham) writes:
>This reminds me of the "limits to software estimation"[1] article,
>which relates the software estimation problem to the algorithmic
>complexity of the problem, particularly in the large problem
>size/complexity limit [I thought this was discussed on this list
>before, but can't find any reference to it].
>
>Funny how everything seems to end up at complexity, one way or another
>;-)
>From my perspective, much of the problem comes from the way we try to
design software: as coherent systems.
Most complex human systems originated organically; no one designed
Paris. Even in the most planned of communities, it's unusual for the
color of the bathroom paint to be strictly specified.
I'd hoped that XML's extreme openness would be an opportunity for this
kind of openness to appear in the computing world, a chance for
developers to accept the chaos that often produces fine results in the
real world, even in the business world.
For the most part, though, I continue to hear "XML is an okay syntax,
but still we must all agree on semantics precisely for anything to
work", the same dispiriting story that's kept complexity as a barrier to
sophisticated computing.
Software developers are happy to design bathrooms and buildings for
other people, but let them choose the paint color? Their preferred
lighting? Perhaps most important, the pathways in and out?
Nope. We have "design patterns" all over the place, but no notion of
the common pattern "ENTRANCE TRANSITION". No wonder we have such
trouble estimating and completing work.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
