Sponsored Link •
A short response to Tim Bray's recent blog post, Doing it Wrong.
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.
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.
I've found that working with owner-types
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.
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?
|Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market.
Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.