Tim Bray's recent blog post, Doing it Wrong has received a fair amount of attention in recent days. In the post, Bray compares the supposedly light-weight agile development approaches used at Web-facing software startups with more formal and heavy-weight processes employed by enterprises, and includes the following observation:

The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise. This is true even when you factor in the greater flexibility and velocity of startups...

This is unacceptable. The Fortune 1,000 are bleeding money and missing huge opportunities to excel and compete. I’m not going to say that these are low-hanging fruit, because if it were easy to bridge this gap, it’d have been bridged. But the gap is so big, the rewards are so huge, that it’s time for some serious bridge-building investment... This seems by far the most important thing for my profession to be working on.

Bray then attempts to dissect the reasons for the great discrepancy, and concludes that technology and culture both play a role in the increased development cost at enterprises.

Readers of Doing it Wrong have already commented that Bray's analysis falls short of mentioning the large number of startup failures. Others have noted that the venture-sponsored development style of startups holds scant relevance for enterprises that must carefully plan the use of limited resources: Managers really must know up-front the cost and delivery times for a software project, and developers, in turn, must be able to estimate those factors accurately at a project's inception.

Owners vs Caretakers

Yet, Bray's analysis as well as the comments to it neglect an important factor that, I think, accounts for a large portion of the discrepancy in the cost and quality of software projects. The difference is due not so much to that between enterprises and Web-facing start-up companies, but to the difference between two types of managers and developers: caretakers and owners.

From a business perspective—Bray's main viewpoint—caretakers use other people's money, whereas owners use their own money, or are at least very significantly and personally exposed to monies invested in a project. More generally, owners of a project or a codebase have very strong personal incentives to make their users happy, be those incentives financial or purely professional. As a result, for owners efficiency and reduced costs are musts, not simply desirable attributes. Caretakers generally have less urgent objectives.

Owners and caretakers are present in enterprises and startups. I've worked with owners of very large enterprises—companies owned by a few individuals as opposed to many shareholders—that insisted on very lean development practices; and also with enterprises where decisions were made by caretakers who had no personal financial or urgent professional stake in the process. But I've seen startups, too, where, although employees had a heavy incentive to make the business successful, the ready availability of venture money made frugality a somewhat remote concept.

Owners and Agility

I've found that working with owner-types forces agile practices on a project: For one, those folks have absolute control over the purse, and you, as a vendor or consultant, simply won't get paid unless you show significant and regular progress. The more frequent the iterations, the better. All the agile practices work to a developer's advantage in such a setting. Also, owners are generally very hesitant to throw (their own) money at enterprise software that can't show short-term return on investment. That, in turn, determines to some extent the technologies used in the sense Bray describes. Finally, owners of successful enterprises are interested in the long-term maintainability and cost of applications—again, agile practices better able to manage change are more suited for this sort of an environment.

Caretaker types, by contrast, are seldom incentivized in the sense owners are: From a business perspective, caretakers may receive a bonus or promotion based on quarterly or annual performance, whereas owners typically have a much longer view. Caretakers also have less riding on a project's success professionally: If a project doesn't pan out, they would just look for another project or job. Owners must please their customers, but caretakers must please their boss above all. As a result, caretakers are more interested in making safe choices: They have to be in a position to defend themselves in case something goes wrong with a project. Caretakers may also be less incentivized to follow iterative practices and deliver regular, measurable results, in part because they typically receive a fixed salary at regular time intervals. For owners, however, nothing is ever guaranteed: they must earn their pay each time they sit in front of a customer.

Bray mentions Basecamp as one of his examples; in that case, all the developers really were owners of a relatively small company. They had clear incentives to make the application lean and clean, and easy to maintain, which then impacted their technology choices. At the other end of the spectrum are large-scale government-sponsored projects, where the owner is the amorphous tax payer and where everyone on the project is a caretaker. Bray mentions some of the more spectacular project failures in that sector.

In-between those extremes are employees of firms that are somehow incentivized to make the best decisions for their companies. The "best" decision may not always be to save the most amount of money or to use the most capable technologies. "Best" requires context, and people are able to appreciate different contexts defined by different environments: I've known folks who recommended and used one set of technologies in their day jobs, and used something completely different in a startup they worked on at night. In one context they were caretakers, in the other, owners, leading to different motivations and decisions.

Should We All Be Owners?

Looking at this problem from the perspective of owners vs caretakers suggests that Bray's blog post is really about an age-old business problem: As soon as a business starts to have employees, or caretakers, an entirely different set of incentives and motivations enters the firm. While an owner-only company may be very efficient at every turn, you can hardly grow a business without employees.

The same is true of a software project, even when it is an open-source project. It may be ideal to work alone or with just a special cadre of developers with deep and personal stakes in the project's success, that exclusiveness restricts growths if the project becomes widely used. While I don't have personal experience with this, I imagine that large open-source projects, such as the Linux kernel or the Eclipse IDE, require more resources than do small projects with a handful of owner-developers.

You need to accept somewhat reduced efficiency in return for the ability to grow and serve more customers or users. That has been the case with many technology companies, from Microsoft to Google: Employee no. 20,000 at Google likely has different motivations from employee no. 5 when making technology decisions.

We can't all be owners, but a company can take steps to motivate employees to think more like owners. Agile practices already promote the notion of "product owner" or even "business owner," and smart firms can make such phrases a fact in business terms, too.

It must also be said that while owners have the right incentives, they don't always make the right decisions. A sizable bad decision can put a company out of business, losing the owners' principal and dashing their hopes.

Do you agree that Bray's argument can be interpreted in terms of how "owners" vs "caretakers" make technology decisions? What do you think of Bray's blog post?