Commodity Programmers

Economists talk about factors of production. They are

In less enlightened times, we had slavery. Labour, in those times, was capital too: people could be bought and sold.

People are now no longer bought and sold as slaves. They are no longer property. But, by many employers, people, in particular those working in IT, are treated as Human Resources , hired on the basis of a standardized set of skills. They have become commodities, like gold or pork bellies.

Commodities such as precious metals are easy to trade. You don't have to check the particular ounce of gold you're buying, as it's the same as any other one (provided, of course, it comes from a trusted source). Often, you don't even see the particular ounce, as it's fungible. Other markets require a bit more care. Woe betide you if you attempt to buy a diamond (as jewellery) before learning a bit about how to value diamonds. Diamonds, unlike ounces of gold, differ from one another. More so, no two houses or businesses are alike. You'd be a fool not to do a survey, or due diligence, before you buy.

Hiring programmers (and other IT staff) is nowadays treated more like buying gold than buying diamonds or houses. One person with the requisite skills is replaceable by another with the same skills. This is easy if the skills sought are common. Skills become common if they are not too difficult.

To help this process, there has been a trend towards certification, and standardization of skill sets. Java has benefitted enormously from this. However a certified Java programmer is not necessarily a good Java programmer for a particular job. To be that, someone has to

  1. know Java,
  2. know how to program, and
  3. possess other skills, which vary from job to job. The certification process measures only a. b and c are harder skills to acquire and take many years longer. They are also harder to measure, so they don't get measured. But ignoring them is dangerous -- see Choice of Language and Programmer Availability

    Becoming a good programmer takes years (see Teach Yourself Programming in Ten Years). Good programmers are craftsmen, not Software Labourers.

    Of course, programmers aren't expected to remain programmers for that long.

    As well as widely known skills such as Java, the latest buzzwords hyped by industry leaders such as Microsoft and Sun are also much in demand. Buzzwords are perceived by PHBs to be the latest "hot" technologies, but are almost always solutions in search of problems. They often aren't hot six months or a year later. Basing recruitment decisions on buzzwords means recruiting solely according to present needs, with no consideration of how the people they hire will perform in the future.

    Having decided that people are commodities, the next step has been to outsource, and have the development done by people you don't even know (or other primates) . The problem with outsourcing, apart from the tab for the social consequences (unemployment of skilled people) being picked up by the taxpayer and society in general, is that the outsourced staff nave no contact with the end users. The result is inevitable misunderstandings about what exactly the code is supposed to do. But they think they can use the waterfall model. This is discredited, and is rightly being taught as discredited in Information Technology textbooks for school students. But dinosaur project managers in industry are still using it.

    One area where people cannot be treated as commodities is research. To do research, you need the right people -- smart people who are able to think creatively (and that means differently), who have a lot of knowledge of things which are difficult to pin down (and so cannot be described using buzzwords). Rather than treat research differently, hardly any research is being done.


    What should be done

    Managers should, instead of hiring people who are easy to replace, hire people who are difficult to replace because they're good, and they try to keep them. (This requires understanding their culture.) They should trust their judgment on technical matters. For software development, they should adopt a Software Craftsmanship approach instead instead of relying on a process or methodology ( using Extreme Programming is probably OK, but you still need good people).

    Talent Shortage, Or Poor Management? makes a similar point: hire talent, not skills.


    This page was linked to from

    and was last updated on Sep 17 at 01:30.

    © Copyright Donald Fisk 2003