2007_10_01_archive

Only for Database Geeks

From today's xkcd:

Posted by Panos Ipeirotis at 11:09 AM

1 comments Links to this post

Monday, October 8, 2007

Implicit and Explicit Changes in Contracts: Rent-A-Coder

I have blogged previously about outsourcing some research tasks using

Amazon Mechanical Turk. Another option that I have been using is

Rent-A-Coder (RAC): I am using this service mainly for outsourcing

basic programming tasks, such as building basic crawlers for data

collection. (Even though someone could argue that students can be used

for writing such programs, I believe that the time of the PhD students

is better spent trying to solve some research problems, rather than

completing basic programming tasks). So far, I have been rather

satisfied with the overall process, although there were glitches from

time to time. (More about the overall experiences in another post.)

However, an incident that happened lately forced me to think seriously

about assigning any important project using the RAC platform.

Specifically, for one of the projects, we ended up disagreeing with

the coder about the specifications. The summary of the disagreement:

* I have posted a project description and the corresponding

specifications.

* The coder proposed a change to the specifications

* I did not accept or reject explicitly the proposed change, but

rather pointed the coder to the contract to see the description

* I accepted the bid

* The coder had 24 hours to review and accept or reject the project

assignment

* The coder assumed that I agreed with the modifications that he

proposed, and

* The coder delivered the modified project, which was not according

to the project specification

After the project was delivered, we could not agree whether the

deliverable was acceptable or not. Since we could not agree, we

resorted to arbitration, which is done by the Rent-A-Coder staff.

According the the RAC terms of service, in case of disagreement, the

RAC serves as a judge and decides who is correct.

The arbitrator, as part of the analysis said:

The coder has proposed a change in the contract.

The buyer has the following options:

A. Explicitly reject the change in the contract.

B. Implicitly/explicitly accept the change in the contract.

The buyer did not reject the change and implicitly accept the new

requirements.

These steps are not described in the terms of RAC, but rather are

devised by the arbitrator. In defense of this ruling, the arbitrator

said that the same rules would apply if myself, as a buyer, had asked

for some extra features to be implemented. In such a case, if the

coder did not explicitly reject them, the coder would have to

implement the extra features, even if they are not described

explicitly in the project description.

And here lies my disagreement with the ruling. My understanding is

that a contract can be modified only explicitly, not implicitly. A

party can reject changes implicitly or explicitly. This setting

effectively gives priority to the statements in the contract (in this

case, project specification) over the changes that are proposed during

negotiations (which can be accepted and agreed upon explicitly).

Otherwise, we have a dangerous precedent, where one party (buyer or

coder) can start proposing an endless list of amendments, and the

other party has to waste time explicitly rejecting the proposed

changes, stating that they are out of the scope of the original

project description.

At least this is my understanding of the Uniform Commercial Code. It

is clear to me that the Rent-A-Coder has the right to rule

independently of the provisions of the code. However, it seems

problematic to devise a new set of undocumented rules when handling

outsourcing contracts, instead of relying on existing legislation. If

not anything else, it does not build trust among the participants in

the RAC marketplace to know that the existing law does not apply in

the RAC contracts.