> That's the point where I say: If you know the subject matter better than > the person giving the orders, it's your responsibility to understand what > they *really* want, and explain that you need to solve the problem a > different way. > > Or quit.
Or carefully put in writing what the choices are and what the consequences are, and give it to your boss and your boss's boss. But really, you're working for someone with a business need, and the business need does NOT have to do with cron and fiddly bits. The business need is going to look something like: "This set of users needs to be able to work with this set of data without being able to destroy it" or "we had this embarrassing thing happen and we don't want it to ever happen again." No matter how confused your orders are, you should be able to find out what *your* boss is having to explain to *his or her boss*. Then you can use that to come up with a more workable solution. If you know and just don't want to tell this group, that's your right, but then you're going to have a much smaller chance of having the group stumble upon the solution to the bigger problem. You're just going to get details about what happens when you fiddle with the bits. _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
