[
Lists Home |
Date Index |
Thread Index
]
Related orthogonally to the flexibility and grunt
work assessment that I do agree with: the problem
I have with so many tools today is that the engineers
have succeeded spectacularly at enabling us to get
information into the systems, and failed almost as
spectacularly at enabling us to get information out.
How many projects have you worked on where the
requirements have been driven almost exclusively
by one culture of the data entry specialists? Udell
makes reference to the social life of XML documents
in his current xml.com article. Isn't this a redux
of what we were talking about in the heyday of
comp.text.sgml?
Over the holidays, I stumbled over a TAG (the mag,
not the group) article that I wrote in 1992 describing
feedback adaptation, enterprise integration, chaotic
systems, and so on. It is 2004 and we are still working
on the same problems. Whoda thunk it...
len
From: David Megginson [mailto:dmeggin@attglobal.net]
It would probably work very well if problems remained constant throughout a
project (like, say, building a bridge across a river), but in high tech,
they do not -- we have only a limited need for people who can create an
algorithm to do a computation in Olog(n) instead of On(log(n)), but we have
an enormous need for people who can track changing requirements and
userscapes and refactor code violently and continuously to match them, and
we have an even bigger need for people who help build consensus and
communities of users. It's mostly flexibility and unscientific grunt work
that brings success.
|
