Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@a...] 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.
|
