eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Programmer training, user support, and the famous “Eliza” psychologist simulation all entered into your many replies to my letter of last week. When I asked how we should address the problem of using IT to answer peoples “real” questions, or for that matter finding out what those questions are, your comments—many of them long and eloquent—reflected your varied situations.
Making IT more genuinely helpful to anyone, for anything, will at some point require the help of application developers—and developers are faced today with more questions about questions (meta-questions, I suppose we could call them) than any other technical specialty. Many current Windows developers, in particular, probably baby-ducked on Visual Studio 97 and therefore must learn more than just a new way of doing things as they move toward distributed applications. They must first make space in their brains for the idea that more than one way even exists.
Its like my reaction to my first week of foreign-language study, five-bits years ago: I suddenly needed a vocabulary to talk about general ideas of person and time, where before Id only needed to understand how to use a particular implementation of those ideas. Visual Basic .Net, with its many changes compared to earlier versions of the language, has often been mentioned as the major example of the similar learning hump facing would-be .Net developers.
One observer had this comment on all the wailing and gnashing of teeth over the new Visual Basic: “Most of the changes are enhancements we have been requesting for some time such as real object orientation, thread support, and better error-handling and monitoring, so it is somewhat disingenuous to claim that Visual Basic .Net is too hard for us timid VB developers when Microsoft simply gave us exactly what we asked for.” That said, VB .Net developers certainly do have to look past “How do I…?” to ask also, “Why would I…?” and especially “What shouldnt I…?” questions. Failing to do so will cripple their migration to Web-based development in general, Web services development in particular, and .Net development most specifically.
Perhaps theres something to be said for learning at least one hugely flexible programming language—even if it is not commercially popular—to serve as a point of departure for all of the others that one may later need to use. One of our eWEEK Corporate Partner advisors, Robert Rosen (CIO at the National Institute of Arthritis and Musculoskeletal and Skin Diseases), recalled one of his college classes that used a language called MAD. “Once you know MAD,” his professor explained, “all the other languages are just syntax variations.” I feel the same way about Common Lisp, but my fellow Lispers are quick to voice their concerns about treating just any language as a lens through which to see others: For example, as one Lisp guru warned just last week in a vigorous on-line discussion, “I oppose using the word pointer when explaining anything about Lisp: You are only encouraging thought in C terms like pointers and memory locations, instead of Lisp terms like bindings and objects with identity.”
When a question reveals that someone is trying to apply familiar concepts in a situation where theres only a superficial fit, continued this posting, “it is not right to tell him how to achieve whatever stupid thing he is trying to do, but one should rather set him straight about his terms and desires.” I wince at the didactic tone of this comment, but the point is worth making. And who am I, anyway, to talk about someone else being too didactic?
Maybe what were really seeing here is a guarantee that a good consultant will have even more business tomorrow than today. As one reader suggested (yes, he is a consultant), the best answer may sometimes be something like: “A simple answer wont solve your real problem; learning enough to use a more general answer will take more time than you should spend on this. Hiring a consultant to do this job is the best way to get what you want.” Paying focused expertise what its worth is, I suggest, the future of the software business.
Automated tools might be a productive way to assist clients and users in clarifying their needs, but past experience with tools such as Eliza (see hyperlink above) has shown the difficulty of writing software that can conduct a good interview—as well as the hazards of letting users think that a machine really understands them. Why not talk it over with Eliza yourself?
Im always interested in what you, or even Eliza, have to say…