Note: I think I've may have asked this before, but I'm not sure.
I've been thinking about writing some stuff about the economics of software development, but not from the usual angle. Instead, I want to write about issues that would make most software developers and managers say "huh?" while making most economists say "duh!"
In the "Mythical Man Month," for example, Brooks pointed out how scalability of teams is limited by communication issues. This was a major revolution to many managers, but any first year economics student would have said "dude, you're talking about diminishing marginal returns." For some reason, software developers borrow from accounting, biology, and a host of other fields but they scratch their head over basic economic issues which have a huge impact on software development and distribution.
Security has positive externalities and thus is likely to be underfunded. Microsoft software often has negative externalities and is possibly overproduced. Had Digital Research understood a simple concept with a horrendous name called "the cross price elasticity of demand", they may not have priced CP/M-86 at six times the price of that pesky little PC DOS competitor, even if it was an "inferior product." Not grasping the implications put them out of business. (To be fair, some claim that IBM set the price of Digital Research's product, but I'm not certain that's the case.)
Can anyone recommend good resources to search for more information like this? I'm more interested in macro than micro issues (as the latter is better understood by business), but anything is worth reading. I'm reading "In Search of Stupidity" right now and it's interesting information but it really doesn't cover the economic aspects directly. Instead, it treats them entirely as marketing issues.
Re:The Economics of Security
Ovid on 2004-05-04T00:16:27
I wasn't intending to diminish Brooks' accomplishment. What he put forward was brilliant. What I meant was that this should have been clearer to people long before. (of course, this is not a problem exclusive to software development)
Brooks
... demonstrated that marginal returns in software development fall off sharply and then turn sharply negative (a highly non-trivial and non-obvious point)... Actually, marginal revenues falling and then turning sharply negative is also basic economic concept. I'm afraid this is a trivial and obvious point -- if you have an economics background.
Part of the key here is the term ceteris paribus, a term widely used in economics to describe the behavior of a system when only one variable changes. If we translate ceteris paribus to mean "all other things being equal," then we can say "for a given project, adding more labor will eventually lead to negative marginal returns, ceteris paribus." The reason that term is so crucial is that in addition to the constraint it imposes, it implies a solution: changing other factors may have other effects. Thus, if we know that merely increasing labor will eventually reduce returns, then other strategies must be employed. Brooks' genius was not so much revealing this trivial fact; Brooks' genius was explaining it in terms that software developers and managers can understand and in laying out what "other strategies" might be useful in avoiding the problem.
In other words, I think this reinforces my point, which I'll reiterate. What you describe as "highly non-trivial and non-obvious point" is, in fact, trivial and obvious if you have an economics background.
And thanks for the link
:) That looks like it will be great stuff. Re:The Economics of Security
btilly on 2004-05-04T01:59:58
I continue to disagree, and disagree in a way that suggests we are talking past each other.
I agree that it is theoretically trivial that it is possible for marginal returns to turn negative in some contexts. The link that you offered points out how that can happen due to simple physical constraints, room in the kitchen, trying to sort out who has the cutting board.
It is a different kettle of fish entirely to show that it will happen in a specific situation for reasons that are hardly obvious, even when you watch it happening. Without knowing what Brooks had to say, it would be easy to be hit with the problem and not understand why you did worse than you expected.
Furthermore I strongly suspect that for most programmers and managers, knowing what the bottleneck is is the important part of Brooks' observation. Knowing that there is a bottleneck, and it seems to hit at fairly small numbers, is of only marginal importance.
Put it this way. You have the following pieces of useful information:This list is in decreasing order of relevance for what general economic theory can say. General economic theory makes the first observation trivial and obvious. It says that the second observation is possible but offers no idea on how likely it is. And the last observation is entirely outside of its scope.
- Diminishing returns are likely. Negative returns are possible in some situations.
- Diminishing returns happen in software development with visible effects at just a few people. Negative returns often set in with small teams. (i.e. To see and understand the diminishing returns that you see in software development, focus on communication overhead. Who spends time communicating with whom? That drives your organizational patterns.
This list is in increasing order of relevance for managers and programmers. The first point is a vague statement of fact which is not actionable in any useful way. The second point gives you a sense of practical limits where you have to start worrying about it. Real life does not always permit you to live with those limits. So the last point says how to see the problem, measure how well you're doing and address it.
So the way that I see it is that general economics says something about the least interesting part of the problem, and is silent on the important parts of it.Re:The Economics of Security
Ovid on 2004-05-04T02:51:24
General economics says something about the least interesting part of the problem, and is silent on the important parts of it.
Bingo! That's exactly correct. I think we were possibly talking past one another because what you wrote illustrates part of the problem. First, you write "negative returns are possible in some situations." That's leaving out a lot. The reality is, negative returns are mandatory for most situations if the manager keeps increasing one input to a system and holds the others constant. In reality, lower marginal returns are usually sufficient to indicate to management that additional resources are not cost effective, so the negative marginal returns tend not to be hit. The economist will recognize a situation but, without further knowledge, may not be able to say what's causing it. The software professional, in contrast, may have a sense that there are communication issues (as just one example), but may not realize the consequences.
That's why I think it's important that software professionals learn how some basic economic concepts apply to what they do. The economist learns to instantly recognize patterns. Once she realizes that secure software has positive externalities, she knows that there will be a tendency to not spend enough money on it, but she won't necessarily be able to tell you why without further study of the system.
On the flip side, a software professional may be railing against management for being too cheap to invest in proper security. However, unbeknownst to the programmer, the company allocates costs from cost centers across all departments in the company and the janitorial staff objects to their paying for computer security claiming (correctly) that they don't use computers and therefore claiming (incorrectly) that they don't benefit from the security output and thus should not have to pay for it (this is known as the free rider problem, another economic concept that many software professionals should learn). Other departments may make similar claims and there winds up being considerable pressure on management to lower expenditures for security and, as a result, security tends to have lower expenditures. This is an oversimplification but it's one reason -- probably not the most significant -- for our security problems.
I mentioned that the economist recognizes patterns and it's fair to point out an analogous trait in programmers. We do the same thing in our own domain. For example, consider the following code structure:
sub XXXX
{
xxxxxxxxxxxx
xxxxxxxxxx
xxxxx (xxxxxxxxxxxxx)
{
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
}
xxxxxxx
}Most seasoned software professionals who encounter that, regardless of the code, will look at it closer for a potential bug. Some might suspect that there's a scoping issue, others may hold off judgment knowing that it might be as simple as the tab versus spaces dilemma. However, if forced to work on that piece of code, no software professional worthy of the name is likely to leave it in that state. So what's the problem with the code? Who knows? It's the existence of poor indentation that clues us into the problem. Again, it's a pattern that is recognized through experience. Like the economist not knowing the specifics of why software security expenditures are likely to be lower but recognizing the pattern, the programmer looking at the above code knows that it's worth a second look, even if the programmer doesn't know there's really a problem.
The benefit of exposing software professionals to economics and teaching them how it impacts their work should thus be obvious: they learn to recognize a new set of patterns. Those patterns don't mean that there's a problem, but the existence of such a pattern is a good indication that a particular issue should be looked at more carefully.
Re:The Economics of Security
chromatic on 2004-05-04T06:11:08
The reality is, negative returns are mandatory for most situations if the manager keeps increasing one input to a system and holds the others constant.Hm, I recall writing a book based on that assumption.
Then again, I also argued just tonight that the amount of work a developer can produce is likely constant in a two year period whether you release the software once or multiple times. Clearly I cannot be trusted with assumptions about work and value!
