… this is really embarrassing as a professional economist — but I’ve come to believe that there may be no examples … of where a sophisticated multivariate econometric analysis … where important policy issues are at stake, has led to a consensus. Where somebody says: Well, I guess I was wrong. Where somebody on the other side of the issue says: Your analysis, you’ve got a significant coefficient there — I’m wrong. No. They always say: You left this out, you left that out. And they’re right, of course. And then they can redo the analysis and show that in fact — and so what that means is that the tools, instead of leading to certainty and improved knowledge about the usefulness of policy interventions, are merely window dressing for ideological biases that are pre-existing in the case of the researchers.
How do you infer the economic well-being of individuals from household income? At one extreme, you could just divide household income by the number of people in the household. This is naive because there are some economies of scale. It doesn’t take twice as much energy to heat a house for two people as a house for one person, for example.
The other extreme is the two-can-live-as-cheaply-as-one philosophy. All that matters is household income; the number of people in the house is irrelevant. That’s too simplistic because while there are fixed costs to running a home, there are marginal costs per person.
So if you have a household of n people do you divide by the total income by n or by 1? Said another way, do you divide by n1 or n0? Some economists split the difference and use an exponent of 0.5, i.e. divide by the square root of n. This would say, for example, that the members of a family of four with a total income of $100,000 have roughly the same standard of living as a single person with an income of $50,000.
Dividing by √n is a crude solution. For one thing, it makes no distinction between adults and children. But for something so simple, it makes some sense. It makes more sense than dividing by n or not taking n into account.
An alternate title for this post could be “Software engineering wisdom from a lecture on economics given in 1945.”
F. A. Hayek gave a lecture on December 17, 1945 entitled “Individualism: True and False.” A transcript of the talk is published in his book Individualism and Economic Order. In this talk Hayek argues that societies must decide between convention and compulsion as means to coordinate activity. The former is preferable, in part because it is more flexible. Individualism depends on
… traditions and conventions which evolve in a free society and which, without being enforceable, establish flexible but normally observed rules that make behavior of other people predictable in a high degree.
Of course Hayek wasn’t thinking of software development, but his comments certainly are applicable to software development. Software engineers are fond of flexibility, but suspicious of rules that cannot be enforced by a machine. And yet there are some kinds of flexibility that require traditions and conventions rather than enforceable rules. Hayek looks beyond the letter of the law to the spirit: the purpose of rules in software engineering is to make the behavior of software (and software engineers) “predictable in a high degree.”
If you trust that your developers are highly competent and self-disciplined, you’ll organize your software differently than if you assume developers have mediocre skill and discipline. One way this shows up is the extent that you’re willing to rely on convention to maintain order. … In general, I see more reliance on convention in open source projects than in enterprise projects.
In short, Emacs expects developers to be self-disciplined and does not enforce a great deal of external discipline. However, because the software is so light on bureaucracy, it is easy to customize and to contribute to.
The quotation from Hayek above continues:
The willingness to submit to such rules, not merely so long as one understands the reason for them but so long as one has no definite reason to the contrary, is an essential condition for the gradual evolution and improvement of rules of social intercourse … an indispensable condition if it is to be possible to dispense with compulsion.
Imagine a rookie programmer who joins a new team and only follows those conventions he fully understands. That’s not much better than the rookie doing whatever he pleases. The real benefit comes from his following the conventions he doesn’t yet understand (provided he “has no definite reason to the contrary”) because these distill the ideas of more experienced developers.
It takes time to pass on a set of traditions and conventions, especially to convey the rationale behind them. Machine-enforceable rules are a shortcut to establishing a culture.
Every project will be somewhere along a continuum between total reliance on convention and total reliance on rules a computer can check. Emacs is pretty far toward the conventional end of the spectrum, and enterprise Java projects are near the opposite end. If you want to move away from the compulsion end of the spectrum, you need more emphasis on convention.
Computer scientist Matt Welsh said that one reason he left Harvard for Google was that he was spending 40% of his time chasing grants. At Google, he devotes all his time to doing computer science. Here’s how he describes it in his blog post The Secret Lives of Professors:
The biggest surprise is how much time I have to spend getting funding for my research. Although it varies a lot, I guess that I spent about 40% of my time chasing after funding, either directly (writing grant proposals) or indirectly (visiting companies, giving talks, building relationships). It is a huge investment of time that does not always contribute directly to your research agenda — just something you have to do to keep the wheels turning.
Most scientists finance their laboratories (and often even their own salaries) by applying to government agencies and private foundations for grants. The process has become a major time sink. In 2007 a U.S. government study found that university faculty members spend about 40 percent of their research time navigating the bureaucratic labyrinth, and the situation is no better in Europe.
Not only do scientists on average spend a large amount of time pursuing grants, they tend to spend more time on grants as their career advances. (This has an element of tautology: you advance your career in part by obtaining grants, so the most successful are the ones who have secured the most grant money.)
By the time scientists are famous, they may no longer spend much time actually doing science. They may spend nearly all their research time chasing grants either directly or, as Matt Welsh describes, indirectly by traveling, speaking, and schmoozing.
Here are a couple variations on the tragedy of the commons, the idea that shared resources can be exhausted by people acting in their individual best interests.
The first is a recent podcast by Thomas Gideon discussing the possibility of a tragedy of the pseudo-commons. His idea of a pseudo-commons is a creative commons with some barriers. He gives the example of open core companies.
The other is Michael Heller’s idea of the tragedy of the anti-commons. If too many people own a resource, the difficulties in coordination may keep the resource from being used effectively. Having too many owners can create problems similar to those caused by having no owners.
If you’re looking for something to blog about, it would be interesting to compare the pseudo-commons and the anti-commons in depth.
… the whole of economics can be reduced to a single lesson, and that lesson can be reduced to a single sentence. The art of economics consists in looking not merely at the immediate but at the longer effects of any act or policy; it consists in tracing the consequences of that policy not merely for one group but for all groups.
Arnold Kling argues in his interview on EconTalk that knowledge is becoming more decentralized while power is becoming more centralized. Therefore more decisions will be made by people who don’t know what they’re doing.
His strongest point is that knowledge is being decentralized. Jobs have become more specialized, academic disciplines have become more narrow, people have become more interdependent, etc. It’s harder to defend a blanket statement that power is becoming more centralized. Kling gives important examples of power consolidation, but one could also give examples of an opposite trend. It would be easier to argue that at least in some contexts power is becoming more centralized.
If in some context power is becoming centralized while knowledge is being decentralized, it is inevitable that more decisions will be made without adequate knowledge. This sounds like a breeding ground for a sort of antibiotic-resistant strain of the Peter Principle.
According to Richard Sears, the world hit peak oil in 1985 in the sense that oil accounted for 50% of world energy in 1985 and the percentage has been declining since then. By that same measure, we hit peak coal in the 1920’s and peak wood in the 1820’s. Sears summarizes
For 200 years we have been systematically de-carbonizing our energy system.
We didn’t stop using wood as our primary energy source because we ran out of trees; we moved on to something better better. Sears believes we are now in the process of transitioning from oil to renewable energy sources, and not because we’re running out of oil. He concludes his presentation by saying
… the Stone Age ended, not because we ran out of stones. It’s ideas, it’s innovation, it’s technology that will end the Age of Oil before we run out of oil.
This post tells the story of two espresso machines: one in Los Angeles and one in Brenham, Texas. But it’s more about deciding what you do and do not want to control.
* * *
In his book Made by Hand, Mark Frauenfelder chronicles his quest to make great espresso at his home in Los Angeles. He reviews some of the tricks to make good espresso from a relatively inexpensive espresso machine. (The machine he describes, a Rancilio Silvia, was around $500 when Frauenfelder bought it. That’s a lot more than a Mr. Coffee, but it’s cheap compared to espresso machines that cost over $10,000.) The problem with inexpensive espresso machines is that they have poor temperature. The water temperature can vary as much as 40 °F. Frauenfelder hacked his espresso machine by replacing its controller with a more sophisticated proportional-integral-derivative controller or PID.
(Small changes in brewing temperature can have a large impact on coffee taste. This is because coffee is chemically complex. Brewing at different temperatures extracts these chemicals in different proportions. See this Scientific American article for details.)
The context of Frauenfelder’s story is his book on doing things yourself, not to save money, but to have more control of your environment. He describes his adventures from growing vegetables to making musical instruments for the joy of doing so.
* * *
Roger Sessions tells a very different story about why he does not have his own espresso machine in The ObjectWatch Newsletter. He describes why he drives 10 miles every day to the Starbucks in Brenham. He says he saves money, even though he spends more on gasoline than the price of his doppio macchiato. For starters, Sessions estimates it would take nearly four years to pay off his hardware investment. Then he lists the things that could go wrong:
Something might break down.
Something could short out his electrical system.
The roaster could burn his house down.
He might not be able to use the equipment well.
The context of Sessions’ story is the benefits of software as a service. Even when it appears to be more economical to create and host your own software, you may save money by paying someone else to offer that software as a service. Sessions pays Starbucks to make his espresso for him because they not only make the capital investment in hardware, they’re also responsible for operation and maintenance. (Update: See Roger Sessions’ comment below.)
* * *
Sessions makes as strong a case for not owning an espresso machine as Frauenfelder makes for owning one. Frauenfelder speaks of the confidence and joy that comes from having detailed knowledge and control of the things around you. Sessions speaks of the hassle and expense of being responsible for the things around you. Both have valid points. I’m sure there are areas in which Frauenfelder is happy for someone else to take responsibility, and areas in which Sessions enjoys fine-grained control. But they disagree which approach is preferable when it comes to making espresso.
One of the things that prompted me to buy Mark Frauenfelder’s book was an interview I heard on a podcast. He said that he was attracted to do-it-yourself projects after becoming editor of Make Magazine. The spirit of the writers rubbed off. At one point in the interview he says DIY is not about saving money; in fact, the DIY approach will often cost more money. I appreciated this comment since many DIY enthusiasts justify their projects with dubious financial arguments rather than simply say that they enjoy what they’re doing and that the extra expense is worth it to them. I suspect Frauenfelder may agree with Sessions on the economics of espresso making, though they have different perspectives of the non-monetary benefits. And although Sessions only argues monetary benefits, he also has non-monetary benefits to visiting Starbucks. I imagine he enjoys getting out of his house, seeing familiar faces, etc.
Unix philosophy says a program should do only one thing and do it well. Solve problems by sewing together a sequence of small, specialized programs. Doug McIlroy summarized the Unix philosophy as follows.
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
This design philosophy is closely related to “orthogonality.” Programs should have independent features just as perpendicular (orthogonal) lines run in independent directions.
In practice, programs gain overlapping features over time. A set of programs may start out orthogonal but lose their uniqueness as they evolve. I used to think that the departure from orthogonality was due to a loss of vision or a loss of discipline, but now I have a more charitable explanation.
The hard part isn’t writing little programs that do one thing well. The hard part is combining little programs to solve bigger problems. In McIlroy’s summary, the hard part is his second sentence: Write programs to work together.
Piping the output of a simple shell command to another shell command is easy. But as tasks become more complex, more and more work goes into preparing the output of one program to be the input of the next program. Users want to be able to do more in each program to avoid having to switch to another program to get their work done.
For example, think of the Microsoft Office suite. There’s a great deal of redundancy between the programs. At a high level, Word is for word processing, Excel is the spreadsheet, Access is the database etc. But Excel has database features, Word has spreadsheet features, etc. You could argue that this is a terrible mess and that the suite of programs should be more orthogonal. But someone who spends most of her day in Excel doesn’t want to switch over to Access to do a query or open Word to format text. Office users are grateful for the redundancy.
Software applications do things they’re not good at for the same reason companies do things they’re not good at: to avoid transaction costs. Companies often pay employees more than they would have to pay contractors for the same work. Why? Because the total cost includes more than the money paid to contractors. It also includes the cost of evaluating vendors, writing contracts, etc. Having employees reduces transaction costs.
When you have to switch software applications, that’s a transaction cost. It may be less effort to stay inside one application and use it for something it does poorly than to switch to another tool. It may be less effort to learn how to do something awkwardly in a familiar application than to learn how to do it well in an unfamiliar application.
Companies expand or contract until they reach an equilibrium between bureaucracy costs and transaction costs. Technology can cause the equilibrium point to change over time. Decades ago it was efficient for organizations to become very large. Now transaction costs have lowered and organizations outsource more work.
Software applications may follow the pattern of corporations. The desire to get more work done in a single application leads to bloated applications, just as the desire to avoid transaction costs leads to bloated bureaucracies. But bloated bureaucracies face competition from lean start-ups and eventually shed some of their bloat or die. Bloated software may face similar competition from leaner applications. There are some signs that consumers are starting to appreciate software and devices that do less and do it well.
The latest EconTalk podcast relates a story of people who harbored a grudge against the Red Cross for decades. What did the Red Cross do that was so bad? They sold doughnuts at cost.
The Red Cross had given soldiers doughnuts for a while. Then at some point they started charging a nickle. They were not making a profit, only selling the doughnuts at cost. And they only started charging because the U. S. Army asked them to. Even so, some veterans and their families remained angry about this for many years. To this day, some Red Cross workers bring free doughnuts to meetings trying make up for hard feelings.
If you give away something but make it clear from the beginning that it’s only free temporarily — a free sample, a trial version, etc. — then you may charge money later without causing resentment. But if people ever get the idea that your product will remain free, they feel entitled to it.
If Facebook, for example, decided to charge even $1 a year for an account, they would lose millions of members. People would burn Mark Zuckerberg in effigy. Presumably they could have charged $1 a year without criticism when they started. But since the service has been free, they can never charge for it without creating enormous ill will.
Idea-Driven People come up with Ideas (and Results), more often than Results-Driven People come up with Results (and Ideas).
His quote brings up two related fallacies.
People who are good at one thing must be bad at something else.
People who specialize in something must be good at it.
Neither of these is necessarily true. It’s wrong to assume that because someone is good at coming up with ideas, they must be bad at implementing them. It’s also wrong to assume that someone produces results just because they call themselves results-driven.
The first fallacy comes up all the time in hiring. Job seekers may leave credentials off their résumé to keep employers from assuming that strength in one area implies weakness in another area. When I was looking for my first programming job, some companies assumed I must be a bad programmer because I had a PhD in math. One recruiter suggested I take my degree off my résumé. I didn’t do that, and fortunately I found a job with a company that needed a programmer who could do signal processing.
The pinch-hitter is the guy who sits on the bench and then comes up to bat, often in a key moment of a close game. When I was a kid, I always thought that pinch hitters must be the best sluggers in baseball, because all they do (well, almost all) is hit. But … pinch hitters are generally not the best hitters.
This makes sense in light of the economic principle of comparative advantage. You shouldn’t necessarily do something just because you’re good at it. You might be able to do something else more valuable. When people in some area don’t do their job particularly well, it may be because those who can to the job better have moved on to something else.