At a broader level, the business will be a marketplace for clients
who care about quality to find programmers who can deliver quality,
and vice versa.
The business will focus mainly on two groups of people:
Clients who are looking for specialized software, and have a
clear idea of what they want. The ones I have in mind are skeptical
of conventional wisdom about quality, e.g., that you get what you pay
for, that the best products are the most popular ones, and that the
best programmers are the ones with the most advanced degrees or the
most years of experience.
Exceptional programmers. I mean the kind of people who can write
thousands of lines of new code in a few weeks with hardly any bugs.
I am aware that these two groups are fairly small. It is a sad
fact of life that many clients do not really know what they want,
and of course it is tough to find top notch programmers. I don't
care. I want to cater to these two groups anyway, even if the
business does not make loads of money. The company will be owned
and operated by programmers, and the goal will be to make a decent
income with very high job satisfaction.
Also playing an important role will be people who excel at certain
ancillary activities such as requirements analysis and testing. Their
income will also be based as much as possible on the quality of their
What will make this company unusual will be the terms of payment
spelled out in the contracts. The terms will be quite harsh,
arguably too harsh for many programmers. Each contract will
specify an estimated delivery date along with the fee to be
paid by the client if the software is delivered on that date.
If the programmer delivers early, he earns an additional bonus
linearly based on how much earlier. If he delivers late, a
steep penalty is subtracted from the fee, again linearly based
on how much later. Independent of this, there is a penalty for
each bug found after delivery, scaled according to severity.
For example, the contract might specify that the fee is
$50,000 if the software is delivered on March 31, with a bonus
of $100 for each day early, and a penalty of $500 for each day
late. And it might specify penalties of $25, $75 and $250 for
each low, medium and high severity bug respectively.
A key provision of the contract will be that the programmer
can suffer a net loss if he delivers late enough or if too many
bugs are found. That is, if the penalties add up to more than the
original fee, he will actually have to pay the client money. The
contract will specify a limit to his liability, perhaps around
$5000 in the above example.
The contract is considered over, and actual payment is made,
after all reported bugs have been fixed and a specified amount
of time (say one week) elapses with no new bugs being found, or
when the programmer reaches his liability limit.
One of the major roles of the company will be that of escrow agent.
Both buyer (client) and seller (programmer) will be required to
deposit funds, typically in the amount of their maximum liability.
These funds will earn interest for as long as they are deposited.
When the contract is over, the accounts will be settled, and the
parties will be able to withdraw any remaining funds.
The company will support an elaborate system of arbitration,
designed to resolve disputes inexpensively but fairly. The
arbitrator's decision will be enforced directly by the escrow
agent, thus avoiding any need for a court of law.
The arbitrator will not simply make a decision. One of his
duties will be to write an opinion, addressing each of the loser's
arguments and explaining why they are invalid or irrelevant.
The parties may choose an arbitrator during contract
negotiation to resolve any dispute that may arise, or they
may specify that the escrow agent will choose an arbitrator
in the event of a dispute.
The arbitration system will follow the "loser pays" model
present in some European countries, meaning that the loser will
have to pay not only the original debt, but also the arbitration
fee and a certain compensation to the winner for time spent on
arbitration. This is to discourage frivolous claims, and to
encourage people to concede valid claims promptly. Also, interest
on the original debt will be charged back to the date the claim
A key responsibility of the company will be qualifying
arbitrators. A person applying to become an arbitrator will
need to take a test where a series of hypothetical cases
are presented and the applicant must choose the correct
decision. In another test, the applicant will need to
write opinions for hypothetical cases that are slightly
The Requirements Specification
Each development contract will have an associated requirements
specification. This document will be the fundamental reference
for the arbitrator in the event of a dispute.
The specification must describe in detail the required behavior
of the software, i.e., what it must do. A discrepancy between
the required behavior and the actual behavior of the delivered
software constitutes a bug.
The specification must not dictate the process by which the
software will be developed -- this is always at the discretion
of the programmer. In particular, the programmer is always free
to subcontract any portion of the development, using whatever
criteria he sees fit for choosing subcontractors.
At various times, the client and the programmer may modify the
requirements specification by mutual agreement. In fact, this is
likely to happen frequently. They may also agree to modify the
estimated delivery date and the financial terms.
Bugs may be reported either by the client directly, or
by a third party acting as tester. The contract may
specify that the delivered software will be made available
to a certain group of testers, or even to the general
public. Anyone so authorized may search for bugs either
through actual testing or by reviewing the source code.
To be valid and eligible for a reward, a bug must cause
a consistent failure. That is, the bug report must specify
a "trigger scenario" under which the software consistently
fails to meet its specification. It may often happen that
the client observes an intermittent failure, but is unable
to identify the trigger scenario that causes the failure
to happen consistently. He should then give the testers
as many clues as he can. Whoever finds and reports the
trigger scenario first wins the reward.
In some cases, the correct description of the trigger
scenario will require giving internal information, e.g.,
the sequence of task switches for a race condition, or the
initial contents of dynamically allocated memory for a problem
related to an uninitialized variable. Normally a specialist
is needed for this, but the reward is open to anyone who can
describe the trigger scenario correctly.
If two or more people report the same bug, only the first
one gets the reward.
In some cases, the client will write the requirements specification
directly. But usually, the specification will be composed by a requirements
analyst, someone who specializes in helping clients decide the details
of what the software needs to do.
The company will not have a marketing department per se. The target
client is skeptical, jaded and cynical, precisely the kind of person who
would not respond to a conventional marketing campaign. Instead, one of
the functions of marketing, namely locating prospective clients, will be
performed by requirements analysts.
The most likely prospects, I think, will be upper management at
companies with 100 to 200 employees. Companies smaller than this will
probably not be able to afford our services. And in the larger companies,
the decision makers are likely to be so enmeshed in bureaucracy and
politics that it is difficult for them to care about quality. One
characteristic of a good prospect is that he works closely with the
people who will be using the software. In larger companies, software
purchase decisions are often made by IT departments having little
direct contact with users. Likewise, software vendors are not good
candidates because they are even further removed from users.
A requirements analyst will frequently be a full time consultant
who does requirements analysis when the opportunity arises. When
in the normal course of consulting he encounters a client who
needs something unusual, something not provided by off the shelf
software, he may contact my company to negotiate with a programmer
for a requirements analysis contract. First, though, he should do
some qualification of the prospect. One good test is to explain
briefly how the "draconian contracts" work, and see how the prospect
reacts. If his eyes light up, that is a good sign.
A requirements analysis contract is similar to a development
contract, except that the deliverable is a requirements specification
instead of software. A kind of role reversal is happening here.
The programmer, who will later be acting as seller in a development
contract, is at this point acting as buyer.
The programmer may report bugs against the delivered specification.
A bug in this context is an ambiguity, incompleteness, contradiction
or inaccuracy such that the programmer cannot reasonably be expected
to implement the software without further clarification from the
When all bugs in the specification are fixed and some time has
elapsed with no new bugs being found, the contract is over and the
requirements analyst may collect his payment. In particular, the
payment is not hinged on the success of the later development
contract, or even whether the development contract happens at all.
This is intended to keep the requirements analyst focused on
listening rather than selling.
Once the specification has been written, the programmer may
enter into a commission sales contract with a salesman who will
negotiate for a development contract. Again the programmer is
acting as buyer, and here the deliverable is an executed development
contract agreement, including deposit of necessary funds with
the escrow agent. The salesman will be paid a percentage of
the negotiated base fee. There is no concept of "bug" in this
Frequently the requirements analyst will be a good candidate
to act as salesman, since he has already established a relationship
with the prospective client. However, this is completely voluntary.
One hurdle the salesman will face is convincing the client that the
escrow agent is trustworthy. As the company's reputation builds this
should become easier, but it will never be a trivial step.
In some cases, the programmer will not have this burden of
financing the requirements analysis. For example, when another
programmer is subcontracting to him, the other programmer will
be expected to write the requirements specification for the
subordinate contract. Also, if a client will be posting a
requirements specification for open bidding, then as a matter
of etiquette he should pay for his own requirements analysis.
In its role as escrow agent, the company will provide an
Internet host that will offer services such as the following
via encrypted messages:
An account holder may get status information about his
account, and may transfer funds to his own bank when not blocked
by an outstanding contract.
A client may post a requirements specification for open
bidding, or for bidding by selected parties.
Either party may propose a contract, and the other party
may accept it.
A programmer may report delivery against an active
A client may accept or dispute delivery.
A client or a tester may report a bug.
A programmer may concede or dispute a bug report.
An arbitrator may enter a decision and the associated
opinion for a pending dispute where he is named as arbitrator.
A web site will also be maintained that gives general
information about the company. It will provide services such
as the following to anyone, even without an account:
A user may review the list of requirements specifications
that have been posted for open bidding.
A user may review the list of active contracts that authorize
testing by anyone, and may download the associated software.
The company will do little or no screening of programmers.
Applicants will simply need to take a test of company rules,
to make sure they understand the risk they are taking. However,
new programmers will be restricted to contracts where their
maximum liability is within some threshold, say $100. This
restriction will be lifted when the programmer successfully
completes a development contract with a net profit. This is
my one concession to protecting people from themselves.
Examples of good requirements specifications and good
software will be provided. In fact, the software that powers
the escrow agency and the web site will be a flagship example
of high quality software. It will be in the public domain
(not GPL), and a substantial reward will be offered for bugs
in it, say $1000 for each high severity bug.
The interest rate offered on deposited funds will be somewhat
below what can be safely earned in the financial markets, and this
will be one source of income for the company. A fee may also be
charged for each contract -- this remains to be decided.
An employee of the company will be free to enter into a contract.
In fact, this will be encouraged. The other party will be alerted
that he is entering into a contract with an employee. The employee
will need to deposit funds like anyone else.
Mally No Show
A client may deliberately enter into a development contract with
a progammer where he fully expects the programmer to fail, that is,
to reach his liability limit. The client is effectively betting
against the progammer, the way the mob bet against Ben Shockley
(Clint Eastwood) in The Gauntlet, but without the violence. This
is not only allowed, but actually encouraged, as it helps to dispel
myths about what programmers can do.
For example, a client may need to have a Java application written.
He may enter into two development contracts simultaneously. One
is with a "favorite" who has worked extensively with Java. The other
is with a "Mally No Show", who has worked with C and Pascal, but not Java.
The client expects to use the penalty from the second programmer's
failure to help pay for the first programmer. Of course, if both
programmers are successful, then the client must pay both of them.
Don' Worry 'Bout Your Funds, Mon
For a variety of reasons, I think it may be best to locate the
escrow agency offshore. I will actually be on vacation in the
Cayman Islands the week of the 14th, and I may do some research
into this while I am there, even though the launch of the company
is still quite a ways off.
Also, I think it may be good to allow parties to be anonymous.
Of course, people can always refuse to enter into contracts with
This is only a brief discussion of some of the issues involved
with tying income to quality. I have not even mentioned certain
topics such as maintenance contracts.
While I am reluctant to make a prediction, my goal is that the
error rates (e.g., defects per thousand lines of code) for software
developed in this manner will be at least two orders of magnitude
lower than what is typical for conventional methods such as ISO 9000.
The company will have a direct effect only on a small community, i.e.,
the community consisting of the two groups mentioned at the outset.
But as word of the company's success within this community spreads
to the general population, some people may try to explain this
success in the context of conventional wisdom. At that point,
things could get interesting.