Ethics of Dealing with Evil

[gryphon]

Greetings fellow monks,

I recently had an interesting and extremely annoying situation happen to me at work that resulted in the inspiration for my seeking of assistance from the monks. After following some advice from tye, I was able to find a technical pseudo solution to the problem. However, in reading the posts in that thread, I've come upon a bit of an ethical dilemma for which I write this post.

Background: I am an independent consultant (a.k.a. I own my own company) who works for a small group of clients. My primary client is a small-sized company that handles contracts for a variety of their own clients, but the bulk of these contracts are with groups and teams within a single company, a gigantic Redmond, Washington based software company (referred to hereafter as GRWBSC).

My primary client received a project request from their primary client to build a fairly complex Web application service including user account management, online testing, product catalog, online ordering and fulfillment, and lots of reporting. 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. Sounds like a job for Perl using CGI::Application and HTML::Template.

The service itself was explicitly intended to be hosted by my client's Web site, something that’s been on LAMP (Linux, Apache, MySQL, Perl) since the beginning. When the contract from GRWBSC came in, it mentioned nothing about required or even preferred technology. (In fact, it was really vague about what we were supposed to deliver at all, but that's another story.) Anyway, we worked very hard on this and delivered the system. It was reviewed by the project lead from GRWBSC, and both she and her boss gave the green light to launch. We did so and started maintaining the traffic and service.

A couple weeks later, someone within GRWBSC reported to the project lead's boss' boss that our service, which was and is being used by thousands of GRWBSC employees, was running on LAMP. This concerned him because he expected that if it "leaked out" somehow that GRWBSC was using LAMP to deliver service, badness might ensue in the press. The comments received from this and others within GRWBSC were specifically upset over the fact that NetCraft's site was reporting our LAMP status.

Pleas to reason and facts supporting LAMP were ignored as was proof that other teams within GRWBSC use LAMP frequently for a variety of services. We had to migrate our solution to GRWBSC-only technology. For us, the actual recoding of this solution would not have taken us much time due to the manner in which we used Perl. However, support for this new solution would have been extremely time consuming. Hence, my boss asked if there was a way to forge or spoof our use of GRWBSC-only technology. That's where my original question to PerlMonks came from.

I implemented by means of a forged HTTP header a solution that caused NetCraft's site to report us using GRWBSC technology. 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 using GRWBSC technology by NetCraft.

Meditation: So now the GRWBSC people are happy again, and my client is happy. At no time did I or my client lie to GRWBSC. At no time did GRWBSC actually request that we recode everything to work on their technology. They were just freaked out about the reporting on NetCraft and wanted us to "fix it." There are no documents or phone calls where a specific means of fixing the "problem" were requested.

So technically and legally, my client provided exactly what GRWBSC wanted both prior to the NetCraft reporting "problem" and after. At no time did I actually make any decisions about how to solve the "problem," rather I suggested several options and my client picked the easiest path: spoofing. So my meditation and questions are: Am I ethically liable to inform anyone from GRWBSC? 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? If GRWBSC ever found out about the spoofing (unlikely since we're talking about marketing types, but possible), would not my client have a reasonable position?

gryphon
code('Perl') || die;

[dws]

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.

[Aristotle]

I'm out of votes, I'm afraid. That's exactly my take on the matter, so ++ if I had any.

Makeshifts last the longest.

[chromatic]

When the contract from GRWBSC came in, it mentioned nothing about required or even preferred technology.

Depending on the nature of your client's previous dealings with its client, could it be assumed that this project would use one technology or the other? If not, I'd probably say "In the absence of clear client specifications, I reserve the right to use the best tool for the job." Otherwise, I might worry more about the ethics.

It sounds like you've solved the problem in a simple way. If that's not acceptable, I certainly wouldn't recode the project for free.

[hsmyers]

No! GRWBSC is not your client. Your ethical and business obligations are to your client, not to your client's client. This is not object inheritance, it is a business relationship--don't confuse the two. In point of practice (if not fact...), doing and end run around your client would be highly un-ethical, possibly of illegal as well (depending on the contractual agreement with your client).

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

[RollyGuy]

I agree with hsmyers and remind you that you were honest with your direct contact. Your client (or boss) knows exactly what happened in the situation. She has to have some of the responsibility for the decision. I believe that it is her job to determine the right course of action and merely your job to implement that solution. You have not blatantly mislead anyone (except for maybe NetCraft, but that's a different story). I find business to be shady at times, but that's life.

-Rg

[mjeaton]

I do see some serious issues with this whole scenario. Why, if doing work for GRWBSC, would anyone choose to implement in anything other than GRWBSC tools? I realize that Perl may have been the *best* tool for the job, but any consultant worth his/her salt should know that it's not always about what's best, but what the client wants.

It seems that both you and your client have put yourselves in a bad situation. Your client should have been more proactive in gathering the requirements and having GRWBSC sign off on them. At any step in the process, if you had concerns, you should have let your client know.

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?

IMO, your client is resposible for being 100% honest with their client and showing them some respect. Who cares if GRWBSC is considered evil by many...the fact is, they paid for a solution and had certain expectations that weren't met. A hack to get around it doesn't seem like the ethical thing to do.

Anyway...that's my 2 cents about the matter. I will say one more thing...if you feel comfortable with knowing what you know and not letting GRWBSC know, than don't worry about what any of us have to say. :-)

mike

[gryphon]

Greetings all,

Thanks for the great responses so far. One thing I did forget to mention is the fact that the Web service in question is actually the second we've done for this particular contact within GRWBSC, and it's the fourth we've done for the particular group/team within GRWBSC. All four projects were on LAMP technology, and we were very up front about that on our first contract. No one seemed to care until someone high up got word and got ticked.

I think this makes a world of difference when it comes to delivering something that the client wanted. Who is my client's client exactly? Is it the project lead, the team or group, or GRWBSC as a whole company? As far as my client is concerned, it's the project group/team since the makeup of GRWBSC is very "team vs team".

Regardless, my client via me provided exactly what was requested of us, both in what was requested for the service and what was requested about the NetCraft "fix." If GRWBSC or anyone therein is unhappy with the results, then it can only be because they were not specific.

I feel some responsibility for building the HTTP header spoof since it "feels" like I'm misleading my client's client. However, I don't feel any responsibility for building a Perl solution, even when an ASP one may have been prefered, since any such preference was in no way specified by anyone.

gryphon
code('Perl') || die;

[mjeaton]

Re: Ethics of Dealing with Evil by gryphon Greetings all, Thanks for the great responses so far. One thing I did forget to mention is the fact that the Web service in question is actually the second we've done for this particular contact within GRWBSC, and it's the fourth we've done for the particular group/team within GRWBSC. All four projects were on LAMP technology, and we were very up front about that on our first contract. No one seemed to care until someone high up got word and got ticked.

This makes a difference, but you should still try to bring it up with your client (in a very blame-free way) that better requirements next time may keep you from having to be in this situation.

mike

[grantm]

I'm inclined to agree that you could reasonably have assumed that GRWBSC would want you to use their technology. At the very least they should have been told up front that you weren't planning to. That would give them the option of changing their requirements to be more specific and you the option of re-estimating the time/cost based on the changed requirements.

If you haven't tried PerlEx from ActiveState, you might be pleasantly surprised how easily you can move your apps from Apache to IIS - I know I was. It's not free but your can try it for free and the retail price is probably less than a few hours of your time.

If your application is dependent on MySQL's dialect of SQL, then you could continue to run that on GRWBSC's operating system - NetCraft won't have any visibility on that.

[scain]

I mostly agree with mjeaton. What you have done is probably unethical, but I think if GRWBSC ends up having a problem with it, it is your client who will get the heat. If they get in trouble, they may end up blaming you, and that's not good even if you don't have legal culpability (which you may or may not; IACNAL).

I would suggest that you point out to your client that GRWSBC may be very irritated if they find out that they have been deceived (by omission if not commission), and that between you, figure out what to do. The right thing might be coming clean with GRWBSC, and it might be porting like you know they wanted in the first place (though that will certainly take a long time and cost a lot; who will pay?). Make it clear to your client that this is a problem and it is currently in their lap.

Scott

UPDATE: given gryphon's comment below (that this is the 4th project done for GRWBSC, and the previous three had been using LAMP solutions, I don't see that what he did was particularly unethical. The rest of what I wrote still stands; having a contingency plan is a good idea.

[eol]

I personally think you need to ask yourself can you afford to lose your immediate client, rather than wondering if you are ethically wrong. Will get to that in a moment.

Ethically I personally believe you are abstained from all wrongdoing's if the specific technologies weren't hard coded in the contract and you have been honest with your immediate client. My belief is based on:

1. Lets say I hired you to create solution A. I would expect you to build solution A to the best of your abilities using the best technology. Now my marketing department tells the world I have the best product for anything but I know otherwise. When you deliver me a solution based on my own technology that I know to be substandard, I would be upset. If I am not specifying the exact technology, I expect you to use some initiative and design in the best technology for the job.

2. Lets go on the above stated belief that you should use common sense and if building a product for vendor M, you should use vendor M technology. Well what exactly does this mean? Vendor M makes mice and keyboards; do you have to use these technologies to type your program? Vendor M has a huge partnership with hardware maker I, does this mean you have to use I’s CPU’s? Where does this stop? Unless the technology is specified in the initial contract, this is not your issue. Ethically you are doing the RIGHT thing by giving them the BEST product for their money using the BEST technology for the job.

Now as for my first statement, need to remember the “Shit rolls down hill” principle. No matter how much you document your correspondence and work, your immediate client is under no obligation to contract you for FUTURE work. If they get in a jam with GRWBSC it’s going to roll down to you. Sure you can deny it’s your fault (and prove it with documentation) and you can be sure they will not hire you anymore. Even if they fire your contracting officer, he has friends and they are not going to look kindly upon you. Nobody likes a turncoat (as they will look at it). The contract with GRWBSC is probably worth your contract many times over. Just because it isn’t your fault, doesn’t mean you aren’t going to get burned. That being said, if my livelihood depending upon my immediate client who is doing work for GRWBSC and I knew GRWBSC was a technology only nazi like Vendor M is, I would have bit the bullet and used their technology. If my livelihood didn’t depend on my immediate client, no big deal then. You did what you were contracted to do to the best of your ability with vague contract obligations. They don’t like it, move on.

Lesson to learn from this: When doing business as a contractor or an employee with a project, ALWAYS GET SPECIFIC REQUIRMENTS IN WRITING. You may not believe they will mistreat you and they may promise they won’t, but when shit hits the fan, their job is more important then yours.

[Jenda]

If I read what you wrote right the project lead was afraid of the possible information leakage. I do not see anything being afraid it will not work or something. So if you made sure the LAMP status will not be visible and you and your clients will not talk about it I don't see a problem.

Actualy ... the project I spend most of my time with is supposed to use their technology as well. And well ... it seems it is, the marketing pages about the project say it is ... and it is not. The pages are ASP, but the services ... ;-)

I tried to do as much as possible in VB and VBScript just like I was supposed to (don't ask me why did I take the job!), but some things would take ages to implement in VB. So with the help of ActiveState's PDK I implemented the feature in Perl and use it from the ASPs as a COM object. Later on I added some services completely in Perl, most of the VB code is generated by a Perl script, ...

Am I feeling bad about that? Of course not! I implemented more in less time and everything works just great. I'm just not supposed to talk about it ;-)

Jenda

[bcole23]

I think it's pretty clear there's only one "EVIL REDMOND BASED COMPANY" and you absolutely need to perform as much CYA as you possibly can. I mean it.


Cover Your A$$.


Document everything. Ask a lawyer about your current contract agreement and if anything is off, have them change it. You'd be suprised at how many companies will change their contracts if asked. But you have to ask and in an intelligent way.

However, the way you've operated so far is absolutely unethical to, not the company, but to yourself. DON'T DO THINGS YOU'D BE ASHAMED OF TELLING YOUR MOTHER YOU DID. My personal belief is that you should never do things that are dishonest or misleading, and that's probably why I'm not rich too.

[Steve_p]

Well, unless it is specified somewhere that you should use their products, then I don't see why you should have to use it. If they come back after the fact saying that you must use their products, then you have a change in requirements that would need to be compensated for by that company.

Personally, I don't see what the problem is. A web mail provider is well known to be using FreeBSD, despite the IIS/MS reporting from Netcraft.

[Jenda]

Yeah and the headers of the mails they sent stated clearly they are using Perl+Mail::Sender to send them ;-)

I belive they only turned the header off later. I saw a few messages from Hotmail that contained no X-Mailer:, but they did contain a "bug" that was present in an older version of Mail::Sender.

Jenda

Sorry couldn't resist ;-)

[tadman]

In my opinion, this whole Netcraft-style server software probing is such a silly thing anyway. It was meant for the curious, just like when you connect with SMTP, POP3 or FTP. In the educational context, it's informative. In the commercial marketplace, it's none of your business. People are entitled to their privacy, aren't they? It's not like I can find out what piece of accounting software you're using with a such simple probe.

So changing it is no worse than "lying" about your browser signature when you set it to something specific when using LWP::UserAgent. Isn't that something they call a white lie?

Remember: "A white lie" is a lie that is told to avoid offending someone or hurting another's feelings.

[Reverend Phil]

I'm going to have to go with Butters on this one:
You know, you can call a shovel an ice-cream machine, but it's still a shovel, Mom and Dad. Ah, and you can call a lie whatever you want, but it's still a no-good stinkin' lie! And when you start coverin' up one lie with another why, now that's when you get into real trouble!

-=rev=-

[jepri]

Companies like Microsoft do have a reputation to maintain. Remember the howls of derision when Microsoft tried (and failed) to move Hotmail from BSD to NT? Their critics had a field day. It's reasonable for MS to want to only be associated with MS gear.

Think about the reverse... kernel.org running off a windows machine. A lot of people would see something wrong with that.

You can see why MS marketing people don't want to have to answer phone calls from the press saying "If you guys are so good, why are you using someone elses product? Maybe we should too?"

____________________
Jeremy
I didn't believe in evil until I dated it.

[Aristotle]

I wouldn't even blink if I was told kernel.org ran on a BSD box, though. ;-)

Makeshifts last the longest.

[Mr. Muskrat]

Cover your back if at all possible. Document all of your correspondence with your client.

One must be very careful when dealing with evil. Remember the old adage...

If you make deals with the devil, you are going to get burned.

[blssu]

I work for a car company.

Once we ordered pizza. Imagine our shock and embarrassment when the delivery guy drove up in a Honda. Obviously we couldn't eat the pizza, so we paid the guy and threw it away. Eventually we were able to find a pizza company using our cars. The pizza was a little cold and soggy because of the 2 hour drive, but we were pretty hungry by the time it arrived... that was the best pizza we ever ate. It says so right in the advertising.

[Anonymous Monk]

So now the GRWBSC people are happy again, and my client is happy. At no time did I or my client lie to GRWBSC.

Misleading them to that extent is just as bad. If the GRWBSC people's only goal was to change the NetCraft responses, then you should have been able to go to them and say "I changed the headers, it's all still written with LAMP though."

Better to just be totally clear and cover your ass from the beginning, especially when dealing with GRWBSCs (speaking of which, wouldn't this have been better posted anonymously?)