When Brooks wrote about the "Mythical Man Month", the book was hailed as revolutionary and even today is considered a classic. One of his key points was that adding more programmers to the mix does not necessarily translate to greater productivity. You wind up with inefficiencies in resource allocation (ever stand in line at the copier?) and communication. While many were suprised at his conclusions, no economist would have been. This is none other than a practical example of the law of diminishing returns. It's unavoidable.
I started thinking about this topic recently and realized that software security tends to generate positive externalities and as a result, economics states that it must be underfunded. I've started to take notes about this and organize my thoughts. We keep coming up with examples of why such and such a thing occurs in software development, but rarely do I see surprises. These issues are typically restatements of fundamental economic principles. Since we tend to learn economics in the abstract, I wonder if these things are less explicitly stated because we tend not to make the direct connection between abstract economic terms and reality.
I wonder if it's even worth putting to paper. For many, this is self-evident, but I suspect that the majority of people have no clue that much of what we see in the software development is entirely predictable. For example, one of the reasons why I suspect dynamically typed languages have such a foothold on the programming market is the lowered necessity of having large software development teams. We hear frequent estimates of how many more software developers you have to have to create a Java project as compared to a comparable Perl project. This suggests that as the project size increases, you'll need more Java programmers and approach your zero marginal productivity limit faster. However, you need a higher caliber of programmer to work on Perl projects. An individual Perl programmer can generate bad code so fast that there might be a lot of damage to undo, but the same programmer working in Java will have certain classes of damage that are difficult to have (due, in part, to compile-time exception handling).
Are these specific programming issues that are beyond the bounds of economics? I don't know. Something I want to keep thinking about, though.
