[
Lists Home |
Date Index |
Thread Index
]
On Sun, 4 Jan 2004, Simon St.Laurent wrote:
> 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.
Of course in the organic world, mutatations are mostly failures, and die
off. Project managers seem to want higher probability of success (at least
on the timeframe of the project) ;-) .
> 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.
No one wants to have they app crash for lack of handling some obscure
content model -- and I've certainly seen that happen a lot on the project
I'm working on. I
We need to make sure people use the 'right' approaches for processing xml,
so this doesn't happen. Unfortunately this is a different mindset for
designers and developers ...
|
