Commodity Programmers
Commodity ProgrammersProgrammers who believe and act like programming is a commodifiable service. They are the ones who started programming because someone told them that you can make good money as a programmer, not because they're actually interested in it, let alone good at it. CommodityProgrammers have two fates: move on to some other profession when they realize that programming is not a commodity service, or become journeyman programmers who respect the fact that programming is not a commodity service.
Some say that programming is a commodity service, because anything that one programmer can do can be done equally as well by thousands of other programmers (and that this is a good thing; the growth of programming is based on it being a commodity service and if it were not so, 99.9% of us would be out of a job).
However, GrandMasterProgrammer and the research that backs it up shows that some programmers are orders-of-magnitude more effective than other programmers. This alone disqualifies programming as a commodity service. Programmers are not easily interchangeable. [Note: The GrandMasterProgrammer link does not support the previous statement. From that page "the best programmer and the worst programmer in an organization have productivity ratios near 10:1." This is less than an order of magnitude difference between the single best and single worst programmer.]
Try looking at work of WilliamEdwardsDeming for an alternative view. The truth is that "superstar" programmers are few and far between. If a software project is dependent upon having such a programmer, the project is doomed for failure; the typical programmer makes or breaks the project. Programming is a transferable skill, one can carry programming experience from project to project, hence it is a commodity.
Many times GrandMasterProgrammers? become disenchanted, and leave a project abruptly. This is a huge risk to take on that has crushed many a company. Therefore, entrusting projects to GrandMasterProgrammers? actually adds risk to a project.
What can doom a project lucky enough to have GrandMasterProgrammer is that he or she rarely has the freedom, the proper tools, and the proper working environment to do Grand, Masterful work. When they do find such a place, they don't tend to leave it, so few readers here have met GrandMasterProgrammer.
Enough Grand Master Programmers abound to create most or all of the software that now gets generated, albeit slowly and badly, by people with no innate ability for programming. They're not so rare as to be insignificant. The previous paragraph is intended primarily to address the skewed attitudes that appear in this and other forums about GrandMasterProgrammer from people who have obviously only witnessed Better Than Average Programmer. Now it can be nice to have Better Than Average Programmer, but the average is so very low that you're still talking about people who lack, hence the complaints. [More later.]
[Check your math. The numbers presented below, if we choose to accept them, show that the Grand Master Programmers could only produce 1/3 of all the software that currently gets developed. (5% x 10 productivity units) = 0.5. (5% x 10 productivity units) + (95% x 1 productivity unit) = 1.45. (0.5/1.45) = 0.34.]
Regarding the existence of GMPs: The term was invented to describe a subpopulation of programmers which was identified by research to exhibit a 10:1 productivity improvement over their less-endowed colleagues. That research has shown that this is about 5% of all programmers. Since the term is in relation to the research, there's no need to argue about it, just look at the research. [see GrandMasterProgrammer for references]
The phrase GrandMasterProgrammer was invented (by me) on WikiWiki. Since the studies and RapidDevelopment did not give a name to the concept, I made one up. They just talked about the ratio, I said "A GrandMasterProgrammer is one of those rare individuals who happens to be on the '10' side of things." It is intended to invoke the image of the chess grand master who can play 10 simultaneous games against 10 novice or intermediate level chess players and beat them all ... literally blind-folded.
The definition is likely to morph over time. My original definition was on-the-fly, off-the-cuff, and is not set in stone. Let's see where the mutations and variations bring us.
Does the Grandmaster Programmer concept refute the Commodity Programmer concept? It appears Grandmaster Programmer is based on having Commodity Programmers at two grade levels: Grandmaster and Other.
If it were easy to tell the difference between the two, I'd say that the situation would be closer to multi-level commodity than it is now, but still not quite there. There are (at least) two things standing in the way: 1) It is not easy to tell the difference without spending considerable time, and even this won't give you an accurate measurement, precisely because 'productivity' is not precisely defined (although we all have an intuitive sense of what the word means). 2) Consider professional team athletes such as football, hockey, soccer, or baseball teams; all of these players may be 'grand master' level, but if you suddenly replace one key member, the whole team could fall apart (e.g. WayneGretzky? in his prime). That's why professional sports either have extra team members available to fill the gaps or they only do their trading off-season so that there is enough time to train the team together with the new players. Software companies don't tend to have that luxury of picking and choosing when to replace their staff.
1) is the "5 years experience" problem, and 2) is the fundamental non-linearity, team-gelling, non-interchangeability, PeopleWare problem. Programming is both hard to quantify and hard to predict.
According to Merriam-Webster:
Definition 1
commodity: an economic good: as a: a product of agriculture or mining; b: an article of commerce especially when delivered for shipment; c: a mass-produced unspecialized product
'Unspecialized' is the key word here I think. The vast majority of programmers are not specialized. Operating systems, languages, APIs, protocols (you name it) are all generic skills. Employers can easily find someone with exactly the same or very similar combination of buzzwords on their resume. Productivity and design/code quality are, unfortunately, out of the picture in most cases. Therefore, I would argue that ~95% of programmers are CommodityProgrammers. I would further argue that ~5% who are not, are such because they possess highly specialized (and sought-after!) skills, not because they are so-called Grand Master Programmers.
See JobMarketAdvice for one particular example of specialized skills.
According to http://www.investorwords.com/c5.htm#commodity:
Definition 1
commodity: A physical substance, such as food, grains, and metals, which is interchangeable with another product of the same type, and which investors buy or sell, usually through futures contracts. The price of the commodity is subject to supply and demand. Risk is actually the reason exchange trading of the basic agricultural products began. For example, a farmer risks the cost of producing a product ready for market at sometime in the future because he doesn't know what the selling price will be.
Definition 2
commodity: More generally, a product which trades on a commodity exchange; this would also include foreign currencies and financial instruments and indexes.
The key word here is interchangeable. See PlugCompatibleInterchangeableEngineers. The idea that any generic programmer is as good as the next. As you say, they are all unspecialized, so they're commodities. But even unspecialized programmers (having no specific strengths) are not interchangeable. If a generic programmer has been working on project A for a year and you try to replace him with another generic programmer who's never heard of project A, you will quickly see that programmers are not interchangeable. Try the same experiment with a piston or gear, and you will see that they are interchangeable (if it doesn't work the same as the last one, you can rightfully conclude that it is defective). If people assume, as they do very often these days, that programmers are interchangeable commodities, they will pay a hefty price, as they are soon to find out.
Commodities tend to be low margin. That is, the producer of the commodity only makes a little bit of money beyond the overhead to produce. Furthermore, the consumer of the commodity doesn't care where he gets his stuff (since one's as good as the next, like potatoes or something), and consequently shops around for the lowest price. You won't get that in a dictionary, but that's what it means to be a commodity. People who think programmers are commodities think that programmers are like sweatshop workers and will eventually be packed into sweatshops in third world countries. They also think that they can shop around for the cheapest programmers, since one's as good as the next (they're not 'outsourcing' to India because they think the programmers there are better, despite what some people might think).
The above sounds like a complaint that does not have anything to do with programmers as commodities. Commodity merely means many sources. Attributes such as low margin, indifference to quality, or "sweatshops in third world countries" are not supported by the definition nor in practice.
Both programmers looking for a job and companies looking to hire programmers have based all their assumptions on programmers as commodities.
We were talking about the definition of commodity, so I don't know why you think it's a complaint. These are simply observations. For instance, name one actual commodity (leaving out programming for now) that isn't low margin. I can't think of any. And I never said "indifference" to quality, I said that actual commodities are interchangeable. It's people who mistakenly believe that a non-commodity is a commodity who are indifferent to quality (until low quality inevitably causes problems). E.g. Buying a car. You can get a cheap car, but it will break down more. Therefore cars are not commodities. If you don't care about the quality, you'll end up with a lot of hassles. That's not a complaint, that's a fact. And when it comes to commodity labour, what better demonstration than the sweat shop? Where does Nike make its shoes? Where are most cheap clothes made? How about a big chunk of the car manufacturing labour that MichaelMoore wrote about in RogerAndMe? and DownsizeThis?? And billions of other examples. The labour is not skilled, but buying robots is still too expensive, so the labour is done in sweat shops.
It is not possible to hold a discussion if you persist in using your own, private definition. If your definition of commodity is 100% interchangeability, then I agree; there are no commodities, either for programmers or anything else. The more traditional definition of commodity recognizes that there is differentiation amongst commodities; there are differences in quality and profit margins among vendors.
Actually, it's a rather common definition in economics. I'm quoting it, I didn't make it up. Are you surprised that the MerriamWebster definition is different than the technical definition? I'm not. The dictionary isn't exactly precise.
If the definition of commodity you wish to use is something "which investors buy or sell, usually through futures contracts," then I agree, by that definition, programmers are not commodities. I believe the intent of the page was to discuss something closer to first Merriam Webster definition posted.
Not really, since I started this page as well. The definition I'm using revolves around the word 'interchangeable'. I mean, honestly, hasn't anyone else heard someone say something along the lines of, "He treats his workers like commodities."? That's the meaning I'm going after. Dictionary definitions are irrelevant if real people use the word differently.
Please provide the definition you wish to use and move the appropriate discussion under that heading.
Both programmers looking for a job and companies looking to hire programmers have based all their assumptions on programmers as commodities.
Yes, that's exactly the problem I'm trying to illustrate. Have you recently tried looking for a job with the assumption that programming is a commodity? Have you recently tried to hire someone with that assumption? People in both camps will tell you if you haven't experienced it yourself: It's hell. Largely because the assumption is just plain wrong. See the AskTheHeadhunter website for a great refreshing perspective on this whole problem.
How could any software project ever get started without the assumption the programming is a commodity? How could I ever commit to starting a software project if it was dependent upon finding the specific "software programming artiste" to complete the project; what if the scale of the project required 10 of these unique individuals? What would happen to an existing project if a programmer should quit, retire, or die? Do I terminate the project because he is irreplaceable, or do I hire another programmer with the expectation that he will be an adequate replacement. The current size of the software industry is dependent upon programmers as commodities. We programmers are making out pretty good as well.
Answer: Programmers learn. Commodities don't.
This is rather facetious statement. The fact that programmers learn actually supports the argument that most programmers are CommodityProgrammers. As pointed above, companies hire programmers with the expectation that they can quickly come up to speed (read: learn the specifics of the project).
Ask a silly question...
The fact that they have to 'get up to speed' at all disqualifies them from being commodities. If a gear breaks in my machine, I replace the broken gear and it starts working again. If a programmer leaves my company, all bets are off on how long it will take for a new programmer to get up to speed. It depends on the skill of the old and new programmers, and that skill is not easily evaluated. If programmers truly were commodities, I'd just call my local temp agency and hire a temp programmer or something equally unrealistic.
Analogies grow weak when extended too far, especially when the analogy comes from an environment none of the participants is familiar with. The reality is that one would probably need a very specific part number to replace a gear in a machine; that variation exists; one will probably make a decision on whether to purchase an original manufacturer product, a clone product, or a used product; due to wear, tear, and manufacturing variation it may take considerable effort to install the new gear in place of the old; and the life expectancy of the new gear will also vary widely.
A better analogy may be AA Batteries. One can buy AA Batteries any where in the world and they will fit and function within the equipment. The quality of the battery varies greatly. When someone designs a new product to use AA Batteries, he does not specify that only a single, top of the line battery may be used, rather he treats the battery as a commodity and plans for an adequate life time from a typical AA Battery.
Problems with the battery analogy:
Software development experience is probably the least valued on the market of any profession. I think this is mostly because many managers focus on quantity instead of quality and long-term issues. They want to chase buzzwords more than chase sound solutions.
In my experience, I have seen the opposite. In software job ads, resumes, proposal efforts, etc., years of experience is almost a mandatory clause. Rather it is other professions that rely on things like certifications to indicate ability rather than years of experience. [I am not saying one is better than the other, just comparing the two.]
But then, years of experience has become a bit of a buzzword in itself. See FiveYearsOfCeePlusPlusRequired. Remember the times when people were asking for "Five years of Java experience required", back in 1997? Now it's "Five years of C#/.NET experience required". It's like they're trying to buy widgets for their software building machine and they're ordering one SoftwareDeveloperWidget? which has 6 units of Foo and has one of those diploma things attached to it.
5 years experience, right? 5 years experience doing what? Can you actually do the job? It doesn't matter as long as you have those 5 years of experience listed on your resume.
I suppose there is a difference between valuing general software development experience and valuing specific tool/language experience
Re: 5 years experience doing what?
This sounds like a continuation of the rebuttal of the original statement.
So?
Programmer as commodity use case analysis:
A programmer is a commodity at the beginning of a project, but not later. (Given that certain minimal requirements are met, one programmer will do as well as another--a commodity by definition.)
A programmer may be a commodity after a project is completed. (Commodities have a limited term of usefulness. But, see below.)
A programmer is a commodity when only staffing levels are under consideration. (Commodities are valued by quantity.)
A programmer is a commodity when departments are reorganized without reasonable cause. (Ala Dilbert. A quantity of a commodity may be subdivided without concern for individuals.)
A programmer is not a commodity after his company has effectively invested sufficient quantity of experience and training and recognizes a reasonable return on that investment. (Don't get cynical now. True, his company may still percieve him as a commodity, but it'd be wrong, wouldn't it? When something's value increases with time or investment it cannot be a commodity. Fine wine comes to mind...is a really old, well cared for bottle of Ripple worth more than the one on the self?)
A programmer is not a commodity when his skill set and experience are an ideal fit and the combination is very rare. (Rarity is an antonym of commodity.)
More?
-- BobBockholt. Who, at sundry times, has been all of these.
Programming is a transferable skill, one can carry programming experience from project to project, hence it is a commodity.
Do not confuse personal-programming-skill-as-a-commodity with programmers-as-a-commodity. You're looking through the other end of the telescope.
See ProgrammerStereotype, PlugCompatibleInterchangeableEngineers
EditText of this page
(last edited November 20, 2007)
or FindPage with title or text search