Army Of Programmers

A large potential labor pool. One way for management to mitigate personnel-related risks is to make sure that a project isn't dependent on a hard-to-find skillset; in other words, has a desirable TruckNumber. The more programmers there are in the marketplace with a given skillset; the less risky the skillset is.

One effect of this is it increases the BarrierToEntry to a new technology. The new technology isn't acceptable to management until there are an ArmyOfProgrammers who are proficient in its use; many programmers/SW engineers who are in it for the money rather than as a hobby are reluctant to learn a new skill unless there is significant observable demand for that skill.

Two ways around this:

If the new technology has a MajorCorporateSponsor?, said sponsor can spend money to overcome the BarrierToEntry. A fine example of this is JavaLanguage, which went from being a research project at Sun (and other places, see the entry on JamesGosling) to a major component of IT infrastructure in a matter of years. How was this accomplished? JavaLanguage is decent technology, arguably better at IT stuff than what was in common use at the time (VisualBasic, CeePlusPlus). Best language out there? Probably not. However, SunMicrosystems spent millions and millions of dollars marketing (hyping) Java, touting it as the CureForCancer, etc. And it wasn't just a marketing campaign; Sun also spent lots of money on tool development, training, and the like. It should be noted that the MajorCorporateSponsor? must be competent--having XeroxCorporation as a MajorCorporateSponsor?, for instance, has long been a death knell for technology (unless it was subsequently "discovered" by Apple or Microsoft.)
New technologies can be adopted without a MajorCorporateSponsor? if they a) have a high degree of "geek chic", b) solve a key problem well, and c) can be snuck in the back door. (To be snuck in the back door they have to be free.) PerlLanguage and LinuxOs both achieved mainstream status in more or less this fashion--they were both deployed in inconspicuous applications ("glue code", print servers, etc.) where they proved their mettle. Many such deployments were kept below management radar for quite a while.

Unfortunately, there is a hole in this way of work. Quantity does not mean quality. And many corporate bosses and HR people can not distinguish between good programmers and bad programmers. ( See the MarketForLemons? ). And when there is a lot of programmers, there is also higher probability of hiring bad quality programers.