I think one of the reasons why the software industry fails to fully understand the Brooksian theorem is that software is so pliable that it is _easy_ to believe seriously that the best solution can be produced _easily_, that software is the _heart_ of the system and therefore _has_ to be a single production. i.e. at the heart of the developer’s automatic attitude lies such grandiose assumption, and of course the nemesis… A dam, highway, railroad, television receiver, cpu, political party or a business is never designed and produced with such attitude. These works are no less critical in their contexts yet in every case the developer goes about the production with a definition and discipline of value accretion. The virtual nature of software makes it hard to get real.

The very real Moore’s Law could be making the problem exponentially worse.

One solution to this problem might be for the software consumer and producer to use time and money metrics in defining the value of the product, instead of only time or only money, or worse leaving it to ‘convention/standard/expert’. The consumer ought to speak in terms of times and monies, if the software business is to see any improvement, I think.

Paradigm shifts lead many to think they needed to reinvent the wheel and, in the process (yes, I realize I’m mixing my metaphors), throw out the baby with the bath water. As an old IBM mainframe programmer newly hired by a company making the shift to client-server in the 90’s, I was amazed that they were all of sudden uninterested in things like source control, development methodologies, coding standards, QA, etc. The thinking seemed to be that this sort of infrastructure was a mainframe concept and didn’t fit in with the new paradigm. The company is in the process even today of trying to build in infrastructure and solid project management after the fact. I think of it as trying to pour the foundation after the house it built.

The other reason I think we’ve not held to Brooks’ rede is that IT, especially outside of the pure software development industry, is managed by non-IT managers. I’ve seen accountants and others in CIO slots all too often. When they’re willing to listen to the IT specialists that work for them, it can be a productive partnership but they’re all too often distrustful of those specialists. Many CIO’s don’t really seem to understand the process of software development and they’ve never heard of Brooks’ Law. If you’re an accountant charged with cost cutting, you don’t want to hear analogies about poets and pregnant women. You want to know how many programmer units it takes to get the job done so that you can figure those units into your budget. The notion that programmer A’s hour is rarely equal to programmer B’s hour is enough to make you tear your hair out.