|Just another Perl shrine|
Re: Ethics of Dealing with Evilby dws (Chancellor)
|on Oct 16, 2002 at 20:52 UTC||Need Help??|
The project lead from within GRWBSC has been notorious for providing minimal if any documented requirements and for changing her mind frequently regarding functionality. In another words, I had to build a system that was extremely flexible so as to rework major sections at the drop of a hat to hit a moving and often zigzagging target.
It helps in these situations to distinguish between business problems and technical problems. Nearly everything you've layed out is a business problem with technical implications.
Minimal requirements documentation and frequent post-contract changes indicate a business problem. Your client's contracts people are either letting themselves be steamrolled, or are falling down on the job.
Hence, my boss asked if there was a way to forge or spoof our use of GRWBSC-only technology.
This is your boss, possibly compounding the problem by making a dubious business decision (i.e., to fib).
My client's CEO then wrote a carefully worded email to the project lead at GRWBSC informing her that the site on which her service was running was now being reported as ...
This is the CEO, either fixing the problem or doing proactive damage control (it's hard to tell which).
Am I ethically liable to inform anyone from GRWBSC?
No. That's already been done, via your client CEO's carefully worded memo. You reported honestly to your boss. You're absolved.
Am I or my client ethically responsible for recoding the GRWBSC Web service at no extra charge to GRWBSC even though technology-specific requirements were never discussed?
Absolutely not. It's not an ethics issue at all. It's a business problem, caused, in large part, by your client's contracts people's inability to manage requirements and requirements changes. Your client may make a business decision to recode the service at no extra charge.