Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday May 03, 2004
12:05 PM

Software Economics

[ #18604 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • This [] is an excellent resource for the topic. Many of the "economics of security" issues can be translated pretty directly into the economics of software issues other than security.

    An incidental note. You've made the "diminishing marginal returns" comment to me before about what Brooks said, and I've always felt like it missed the point. Yes, everyone knows that there are diminishing marginal returns. Brooks identified a major cause of that in software development, showed people what it looks like when
    • 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'

      • 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 wh
        • 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 cons

          • 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!