Re: User Defined Fields - HELP PLEASE!
Date: 23 Feb 2005 18:59:37 GMT
Message-ID: <Xns9606857746A63ebohlmanomsdevcom_at_130.133.1.4>
"Mark D Powell" <Mark.Powell_at_eds.com> wrote in
news:1109085151.733741.130640_at_l41g2000cwc.googlegroups.com:
> I will take a contrary view. If the user wants user defined columns
But you have to distinguish between the (IMHO rather unlikely) case where
the user *truly wants* them and fully understands the implications, and
the (IMHO much more common) "XY problem" where the user has some
(unexpressed) need to solve problem X and has jumped to the conclusion
that a particular solution Y (in this case, user-defined columns) is the
> then perhaps he or she should have them.
Since Parkinson's been brought up in this thread, I'll bring up Lawrence Peter of Peter Principle fame. He emphasized the importance of specifying a solution in terms of the problem it solves rather than the form it takes (writing in the 1970s, he said that your goal should not be to develop the best home movie camera by 2000, it should be to develop the best live-action recorder, predicting correctly that other technologies would supplant home movie cameras).
So in a situation like this the job of the DBA, programmer, architect, etc. is to dig in and discover what real need underlies the user request, and only then implement a solution. Or, to put it bluntly, look at the problem in business terms rather than technological ones. It's part of what I like to call the non-geeky aspects of IT (in fact, sometimes a proper analysis reveals that the best solution to the need is a nontechnological one!). Merely pointing out the technical problems with Y won't do it, because the user will understand you as telling them that X can't be solved at all, which they will in fact know is incorrect (they're right that X can be solved, just wrong about how to solve it). The result will just be resistance and pressure, and since they're paying the bills, they'll prevail. Received on Wed Feb 23 2005 - 19:59:37 CET