« Christopher Hayes on China | Main | Nicaragua notes (avoid walls!) »
What does programmer productivity look like?
I am unable to judge the details of its contents, but this article intrigued me. The key question is why pay across highly-talented and lesser-talented programmers isn't more unequal. (That's a question I'd like economists to study more generally, given the disparities in productivity across individuals within a firm.) Here is an excerpt:
Software output cannot be measured as easily as dollars or bricks. The best programmers do not write 10x as many lines of code and they certainly do not work 10x longer hours.
Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on. It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.
For the pointer I thank Hamilton Ulmer.
Posted by Tyler Cowen on December 23, 2009 at 05:07 PM in Economics, Web/Tech | Permalink
Comments
Right.
I believe that this is the case across the board, from gardeners to economists to attorneys.
One would think that the better programmer paid by the hour or even with a salary, who could do an 8 hour problem in 1 hour would likely spend 1 hour on the problem and 7 hours surfing the internet (or something else) as, if he completed the work in 1 hour, he would just get more work, but not more pay.
Posted by: Allan at Dec 23, 2009 5:26:32 PM
"I believe that this is the case across the board, from gardeners to economists to attorneys."
Well, not exactly. In my experience as a software engineer, the worst programmers produce negative work and the top programmers are worth 10X as much as a mediocre programmer. It's a wider range than any other job I've done.
Posted by: KingM at Dec 23, 2009 5:38:43 PM
Things are actually worse than he implies. There are substantial numbers of working programmers with negative productivity, destroying value for their companies every day. They create designs that must be expensively scrapped or rewritten, engender defects that suck up customer support dollars, or in the worst case create products that are essentially unusable and unsaleable. A lot of programmers, even some with over a decade experience, have never successfully shipped code into production. That means that their entire compensation for their careers has been purely wasted dollars. Substantial amounts are spent in software recruiting simply to avoid hiring negative-productivity developers, but it's an uphill battle, and even the best companies slip up at it. Once hired, it can take months to figure out whether a programmer is net-negative productivity, convince management of it, and transition them to a position where they can exhibit positive productivity (or, failing that, negative productivity on somebody else's dime). With information this imperfect and expensive to acquire, it's hardly surprising that compensation doesn't match productivity more closely.
Posted by: Dave at Dec 23, 2009 5:48:01 PM
"I believe that this is the case across the board, from gardeners to economists to attorneys"
The rule of thumb is that only professional athletes have as great a productivity variance as software developers.
Posted by: Dave at Dec 23, 2009 5:52:29 PM
the discrepancy is pretty wide, but there are some tasks that don't require the best programmers.
as in most situations the people who contribute the most to productivity are the ones who can figure out how to avoid unnecessary work and allocate and explain work to others. this requires a lot of knowledge of detail in at least three domains (business domain, technology domain, and the 'soft skills' domain) and it's hard to find people who can do all three.
Posted by: babar at Dec 23, 2009 5:52:59 PM
Isn't this a problem more generally with paying anyone by the hour instead of on a target achievement?
Posted by: Rahul at Dec 23, 2009 5:53:39 PM
It reminds me of all those critical jobs in firms where the person's occupation is to say "no" to lots of people who want to muck up a clean operation. Google has such a person which is why google.com continues to look so clean. Or the standard in the gaming industry to avoid "feature creep;" games are best when they do one thing very, very well. It's a hard job to appreciate because it's built around stopping production instead of encouraging it (or in some cases, taking stuff out). But it's so important.
Posted by: David Youngberg at Dec 23, 2009 5:53:52 PM
One would think that the better programmer paid by the hour or even with a salary, who could do an 8 hour problem in 1 hour would likely spend 1 hour on the problem and 7 hours surfing the internet (or something else) as, if he completed the work in 1 hour, he would just get more work, but not more pay.
this is basically what happens. i know people who have done their masters or studied other degrees on company time.
Posted by: anon at Dec 23, 2009 5:54:11 PM
What Kingm said, and others following.
My consulting specialty is strategic IT planning in the public sector. This scale of productivity differential is especially difficult to reconcile with civil service pay scales and work rules.
Posted by: Bob Knaus at Dec 23, 2009 6:16:51 PM
I'm in a weird job where some of my time is on drawing engineering documents and some is programming. The prograqmming part is just much more ambiguous and open-ended. Nobody really thinks or works much faster than the next guy, but the next guy may not negotiate as actively against scope creep, may not structure code as well or may do unnecessary superflorous touches to a program which are barely used.
The best advice is for software companies to ingrain KISS in their programmers day and night. If you don't know what KISS stands for, you shouldn't be a programmer.
Posted by: mw at Dec 23, 2009 6:20:10 PM
My experience is that it's pretty obvious after a few months who's mediocre and who's the superstar. The problem is communicating this to management.
Posted by: q at Dec 23, 2009 6:32:52 PM
xkcd recently had a comic along these lines
http://xkcd.com/664/
Posted by: rob at Dec 23, 2009 6:52:12 PM
There are essentially three problems that make it hard to set developer compensation based on their contribution:
1. Its extremely hard to measure the quality of development decisions. Properly understood, the job of developers is to understand and solve problems, and the understanding part in fact takes most of the time. So by definition team leaders cannot follow in detail all the decisions their developers are making, let alone communicate that information to the managers who actually set compensation. Its therefore impossible to assess, except in a very vague and imprecise way, how good those decisions are.
2. Its at best difficult to determine the contribution of particular developers. This will make some of laugh, but software development is an intensely social process. Much more so than almost any other white collar job. Its closest perhaps to restaurant cooking, or team sports. It requires constant, clear, intensive communication and precise coordination between developers and between the development team and their "customers" to make it work. Its extremely hard to even remember who had a particular idea once its become part of the accepted lore within the team, and even then credit may be unclear - was it the guy who had the idea, the guy who wrote the code, or the guy who tested it and spotted the vital flaw that deserves the credit?
3. Its impossible to measure the impact of development decisions on the company's bottom line. The main contribution of development to sales is in not screwing up, and its necessarily difficult to figure out what's not wrong with the prodict that could be wrong with it. No-one is going to get a bonus for the application not crashing, or the file dialog not coming up in the wrong directory all the time. Its a strangely rarely remarked on part of the silicon valley compensation model that sales and support staff get bonuses but little or no equity, whereas developers get equity but usually no bonus. But it makes sense, since developers really determine the quality of a software company's main capital assets.
Posted by: Simon Kinahan at Dec 23, 2009 6:58:19 PM
As a practicing software developer (since 1976) I'd enjoy seeing more research on this topic. I see several issues in my own experience.
No one gets paid for code they didn't write. Yet it is the code that doesn't have to be written that is one of the big productivity multipliers. There is typically no efficiency incentive in development.
There is no objective measure of code quality nor of programmer productivity. Naive measures like lines of code are trivial to game (and developers routinely do so) and are hence meaningless.
The effective quality of the code doesn't become apparent until weeks, months, or in very large code bases (millions of lines) years, after it's written. By that time, exactly who wrote the code is ancient history or even irrelevant because the developer has moved on.
Managers all too frequently knowingly trade code quality for time to market. This can have a huge effect on the long term cost of maintaining the code base, but by the time this is apparent, it is ancient history or even irrelevant because the manager has moved on.
Posted by: Chip Overclock at Dec 23, 2009 7:06:55 PM
These criticisms apply to poorly-run software shops, yes. And yes, those are probably in the majority. But within an organization of competent people, it's not hard to tell who's more productive, even when "producing" means not-writing-code, and reward them for it. The trick is the management must also be competent, which means any software operation run by non-technical folks is doomed to either fail or limp along.
Posted by: Noah Yetter at Dec 23, 2009 7:16:20 PM
OK, so I have a BA in Economics, yet I've spent the past 19+ years working on very complex productivity software (how's that for a commentary on the Economics profession?), so I might be in a bit of a unique position to answer this question. I'll just offer two points:
1) For a variety of reasons, actually measuring programmer productivity is expensive. You can easily spend more trying to measure programmer productivity than you'll gain back by weeding out under-performing developers in a direct manner. Cook attempts to make this point, but doesn't do a very good job of it. If you really want to understand, I'd suggest reading Frederick Brooks' book, "Mythical Man Month," and his "No Silver Bullet" paper. The latter does a particularly good job of explaining complexity as it relates to software engineering.
2) Pay tends to not be all that disparate, but other forms of compensation are. A couple of commentators have suggested this, but "free time" becomes an interesting form of compensation that tends to provide an incentive for unproductive programmers to either self-select out of the profession or into particular projects that are less complex and demanding (and, thereby, less rewarding) than more productive programmers.
Posted by: Rick Schaut at Dec 23, 2009 7:21:11 PM
Also if you want to see what actual technical people think about this, check out the Slashdot comments on the same article:
http://developers.slashdot.org/story/09/12/23/1820214/Why-Coder-Pay-Isnt-Proportional-To-Productivity
Posted by: Noah Yetter at Dec 23, 2009 7:21:51 PM
@Noah Yetter - Developers and managers have an idea of who is good and whose not, but even the best managers will never be able to track who made what decision and what its consequences are. Pay definitely does track performance, but the range is about 2x between the best individual contributors and those who have yet to prove themselves, whereas productivity is about 10x. Pay can't track productivity perfectly because of the extremely uncertainty in tracking decisions, measuring their quality and measuring their bottom line impact. As I said above, I think this is why we give developers stock rather than sales commission.
Posted by: Simon Kinahan at Dec 23, 2009 7:28:13 PM
Isn't this true of almost everyone who doesn't have a "bricklayer" kind of job?
Posted by: Brian at Dec 23, 2009 7:39:52 PM
@Simon Yetter.
Well, a counterexample to your claim would be the hot Wall St software groups, where you see compensation ratios much higher that 2x amongst programmers. Of course, these groups look a lot like trading desks, with people given 30 sq ft each of space, no management, and bosses working alongside junior developers.
Posted by: gorobei at Dec 23, 2009 7:39:53 PM
In "hardware" companies the amount of software work always seems large compared to the amount of electronics work. The electrical engineers often run the projects (otherwise what else could they do with their time) and many would have trouble justifying compensation disparity when they have trouble fully appreciating the productivity disparity that is so apparent to programmers.
Projects or assignments are usually unique enough to introduce significant uncertainty into relative productivity assessment in the short run.
Posted by: Brian at Dec 23, 2009 8:06:54 PM
The reason it doesn't vary more is it is limited by the value of the work and the difficulty of keeping the truly productive busy with other than make work. Few companies have tasks that are extremely valuable or need the most productive worker.
Posted by: Lord at Dec 23, 2009 8:28:14 PM
Judging the power of a problem solver by their programming skills? A smart high school kid can come up to speed on a language in two or three weeks. Hiring programmers is still an oddity and we don't have it quite right.
Posted by: Mattyoung at Dec 23, 2009 9:21:42 PM
In my experience as a software engineer, the worst programmers produce negative work and the top programmers are worth 10X as much as a mediocre programmer. It's a wider range than any other job I've done.
Just want to say that, based on my experience in the software business, this is absolutely correct. The gap between adequate and outstanding programmers is enormous. I find it hard to believe that the equivalent gap in any other profession is as wide.
Posted by: Bernard Yomtov at Dec 23, 2009 9:36:16 PM
Thanks for the link.
I agree with the comments about negative productivity. The worst programmers create work. As David Parnas said here, "One bad programmer can easily create two new jobs a year."
Posted by: John at Dec 23, 2009 9:38:27 PM
Welcome to the world of Dilbert...
Posted by: Albert Farangh at Dec 23, 2009 9:39:10 PM
If you don't know that programming isn't about writing code, then you shouldn't be a programmer. Unfortunately, almost every college course related to computers make it all about programming.
And I'm not surprised that an economist thinks its all about lines of code. Economists think making cars, toasters, etc., is all about numbers produced and minimizing the number of low paid workers. After all a $100 crap product is the same as a $100 high quality reliable product when the economists computes the GDP. That the American company is bankrupt in a few years while the Asian firm dominates the market doesn't show up in GDP.
The cost of bad code has been hidden by advances in semiconductors, where the metric that matters most of all is defect rate. The firms that survived were the ones who placed all the emphasis on quality, halting output if it was too low, and ultimately ended up with high volume and low cost. Programming over that same period has been marked by quests for the holy grail of quality without effort in a seemingly endless stream of new programming languages and paradigm fads.
The post yesterday about the Afghan dependencies is a simple rendering of many real world software systems - hundreds of mostly anonymous programmers have contributed to the system, but if the code of just a few of them isn't right, the entire system is as dysfunctional as Afghanistan.
But who am I to complain; I got paid very well for my role in test engineering: figuring out which part of the system was causing the system crash, data corruption, or any of a hundred other problems. Then came getting the guy who wrote the code to figure out the problem and fix it. For those devoted to cranking out code, they seemed to view me as the problem: how dare I tell them their code was wrong.
Now think about the compensation metric for test engineers. Should they be paid by the number of days they delay shipment to fix showstoppers? If that is the metric, then the programmer cranking out hundreds of lines of low quality code is ideal.
Posted by: mulp at Dec 23, 2009 9:56:21 PM
Damn it, Rob beat me to the XKCD comic.
Posted by: Brian Moore at Dec 23, 2009 10:50:45 PM
There's also a processes and systems problem. If you know you have a broad spectrum of programmers of varying ability, and any one of them has the ability to screw your code base up, one very common approach is to require your developers to do a *lot* of work to demonstrate they won't screw stuff up. What this ends up doing is forcing the best programmers to take a massive (and unnecessary) productivity hit in order to protect the code base from the mediocre to poor programmers. If in the normal course of affair an average programmer takes 2 days to do a feature, and 3 days to jump through hoops (and I've seen it that bad) and an above average programmer can reliably do 10 features in 2 days, but still takes 3 days a piece to jump through hoops, then you go from an average productivity multiplier of 1:10 (10 features in 2 days vs 10 feature in 20 days) to 32:50 (10 features in 32 days vs 10 features in 50 days). So even though your best developer is (oversimplifying here) 10 times as productive at writing code... you've hobbled him to less than 2 times as productive in so that you can safely let the lesser programmer work on your code base.
Posted by: quadrupole at Dec 23, 2009 11:01:45 PM
"Programming" is only one part of the process of building good software. Most complex systems are built by a team of analysts, developers, technical specialist (network people, or DBA's) and QA engineers. Good analysts and good documentation can help shrink the productivity gap, so it's likely that organizations smart enough the measure productivity and compensate for high productivity are also smart enough to put in place proper software development methodology.
I would also look offshore for your pay gap. We used to pay about $20 an hour for our engineers in India versus $85 to $90 stateside. The US teams did most of the analysis, design and architecture, passing off the more straight-forward development to our offshore teams. We found our offshore teams were less effective when they had to improvise, but were good enough when they had good documentation to work from. While there are plenty of great engineers and architects offshore, most of the companies I'm familiar with use their offshore teams to manufacture software, not to design or create.
Posted by: DM at Dec 24, 2009 1:02:31 AM
Perhaps an even more interesting question for social scientists: What do the highly productive programmers do to communicate their value to management?
Posted by: LemmusLemmus at Dec 24, 2009 1:36:22 AM
@gorobel - I don't know anyone in development on wall street, but I do know some folks doing those jobs in London. But 30 sq ft of space and an egalitarian culture is normal for serious software development in my experience. The finance guys have higher compensation than the rest of us but I always figured that was due to stress, and to maintain some equality with the traders they work alongside. Plus I guess it's easier to quantify the contribution to the bottom line than it is for companies that sell software. It's interesting that you say there are high disparaties in compensation between developers in finance - possibly the marginal utility on income starts to come into play. Or is there a disparity between those with more dmain knowledge and the straight software guys? The latter would fit my experience in my own field.
Posted by: Simon K at Dec 24, 2009 1:50:36 AM
One problem is that productivity isn't single dimensional. Do you want the code guru who can solve the problem 10x faster than anyone else. Or do you want the code guru who can write code that lesser mortals will be able to understand and maintain 10 years after he's left the company.
As well, very few projects are blank paper designs where the programmer can exercise his skill to maximize his productivity. In fact, there are tons if institutions that do their best to ensure that they can't. Far more important than superstar-dom is uniformity of code allowing programmer fungibility so the project doesn't hiccup when any individual member goes on vacation.
I do remember one friend who worked at a company that (he claimed) let go any programmer that was so good that the department was beginning to depend upon him. To be fair, they also fired the incompetent.
Posted by: Tom West at Dec 24, 2009 2:16:02 AM
I second the comments pointing out the impracticability of evaluating performance accurately. Having worked in an organization that attempts to compensate for performance hyperexponentially (with "Partners" who bring home about 100x/annum what "Software Developers" carry), this creates a strong incentive for political games to move up the org ladders. As a consequence, the worst programmers are most often the best compensated, with the obvious consequences.
Posted by: ms at Dec 24, 2009 2:31:46 AM
I think my value in life is that I'm good at pointing out what shouldn't be done and don't do it. I'm not sure how this can be measured. Maybe I'm just a lazy ass. Or maybe I know something. I'm not sure.
Posted by: rob at Dec 24, 2009 4:45:34 AM
That XKCD comic may be right. But what is left out is that the programmer made $100k in stipend for the last 5 years and in business he made that in last year's bonus.
So, if you want a boss who is qualified to judge your work (and I don't even see that benefit in my experience, in fact to me the cartoon may be the other way around) there is no free lunch. In my experience in business and academics the business boss knows the value, he just doesn't tell you. But, I've had the same experience in academia. There is virtually no difference in that regard.
Seems like there could be computer programs that rate code on some parameters. There could be 3rd party auditors that go around and check code for elegance or whatever you want to call it. It seems like the other programmers know especially if there is cross-checking of bugs so 360 evaluations might help and they should have some incentive to make pay for performance happen. Sometimes just having unreasonable workloads will cause the marginal workers to opt out voluntarily.
Mostly, if noone is good at judging programmers, then noone has an incentive to be good at it. Where are you going to go? The other company that pays crap too (and doesn't know you from Adam)? However, that means there should be a reward for a company that figures it out, or better yet, a company that figures out a software product they can sell that figures it out.
Posted by: Andrew at Dec 24, 2009 5:03:04 AM
The best programmers get rich from stock options in start-ups.
How do I know they are the best? Because they got rich from options in start-ups.
Posted by: Steve Sailer at Dec 24, 2009 5:32:56 AM
"The key question is why pay across highly-talented and lesser-talented programmers isn't more unequal."
In addition to all the reasons cited above, I'd like to add that within large organizations in the U.S. pay levels are fairly well constrained within all professions. Managers have turned over compensation to human resources departments. IMO, HR in most corporations has no clue about how to set pay levels in order to reward productive workers. That's probably why so many programmers work not for large corporations but rather as consultants.
Consultant pay is constrained in large part because it is negotiated by Purchasing Departments. The buyers in those departments contract for x number of programmers at y dollars per hour. They have no way to measure the contribution of each one of those x programmers. So they hire 10 in order to get 2 productive ones.
Basically, as I see it, the pay of highly productive consultant programmers is held down because they do not bargain for wages individually but rather as part of a collective group.
Posted by: John Dewey at Dec 24, 2009 6:03:54 AM
Here is another question. If your management can't parse worker quality, how can they tell you how to improve? If you are a mid-tier but motivated worker, how does that make you feel?
I haven't actually seen good coaching and training on a systemic scale, I think it's kind of a myth, but a lot of people seem to think it exists and should be sought.
Posted by: Andrew at Dec 24, 2009 6:34:52 AM
I used to tell my first level managers, when they got promoted into the job, to stop writing code - their most productive activity now was to make sure the people on their team were working on the right problem, and NOT working on the wrong problem. This was often more difficult that it might seem.
In the area where I mostly worked (technical engineering applications) the biggest problem was really understanding the problem to be solved. The stars were the guys who could extract the real problem, AND write good code. It was pretty easy to identify the top 15%, and the bottom 5% (we had a pretty select group to start with. The middle was much more subjective and situation dependent.
Posted by: Harvey at Dec 24, 2009 10:05:06 AM
"Seems like there could be computer programs that rate code on some parameters."
This is been attempted, but such metrics are trivial to game (really, this is right smack in the skill set of even a mediocre developer). Any more complex static analysis of code quality can probably (if I remember my theory courses from graduate school) be proven to be impossible (equivalent to the halting problem).
"There could be 3rd party auditors that go around and check code for elegance or whatever you want to call it."
"Code Inspection" is a process that is in effect having auditors review code. It can work, if done correctly. Typically the inspectors (auditors) themselves are developers, because there is no one else qualified to understand the code. If you have someone qualified to inspect the code, and they aren't a developer, then you are wasting money when you could be having them develop code. However, I've seen one mediocre developer inspect another mediocre developer's code, and the results weren't pretty.
"Sometimes just having unreasonable workloads will cause the marginal workers to opt out voluntarily."
Truly unreasonable workloads will cause the good programmers to opt out voluntarily as well. Given a hard deadline with a strong disincentive to miss it (like getting laid off), developers, mediocre and otherwise, will simply submit whatever code they have whether it works or not, gaming the system as necessary to pass all the gates. In fact, this is the right thing to do: management has decreed via incentives that schedules are more important than quality. Employees of any ilk really only know what their employer finds important via the incentives that are in place; the latest PR ploy to "improve quality" is meaningless if the incentives don't match.
Posted by: Chip Overclock at Dec 24, 2009 10:05:43 AM
I think one of the reasons why this happens is because 90% of the cost of developing code is spent maintaining that code after it's already been written. Even if a great programmer and a poor programmer can finish the same project in the same amount of time, the real test is how much it will cost to maintain that code over the next x years. A poor programmer has negative productivity precisely because his code costs so much to maintain. So unless you're looking at every piece of code a programmer has ever written along with the future time required to maintain that code you won't be able to measure a programmer's worth very well. Are there other occupations like this?
Posted by: f at Dec 24, 2009 10:10:27 AM
I recommend most strongly Robert D. Austin, MEASURING AND MANAGING PERFORMANCE IN ORGANIZATIONS, Dorset House, 1996. At the time he wrote it he was an executive with Ford Motor Co. in Europe. Now he's at the Harvard Business School, I believe. His Ph.D. dissertation is worth a look too, available from University Microfilm. He frames a model based on agency theory that shows how difficult it is to evaluate all aspects of an employee's performance in an information-based job (like software development).
http://www.amazon.com/Measuring-Managing-Performance-Organizations-Robert/dp/0932633366/ref=sr_1_1?ie=UTF8&s=books
This book changed my whole way of thinking about incentives and processes in software development.
Posted by: Chip Overclock at Dec 24, 2009 10:10:28 AM
@SimonK,
I'm not sure stress is a driving factor in compensation: one paper I read suggested that comp was 30% or so higher on WS for secretaries, etc, as a cheap way to replace "management by managers" with "management by the knowledge that you can easily be replaced if you slack off."
As for some equality with traders, that isn't a big concern. However, it is easy for the traders to see that developer X seems to get useful software on the desk in a few hours, while developer Y never seems to deliver: at that point, the clients are almost directly paying the developers, so easier to quantify performance and no sales force overhead.
Domain knowledge is certainly a factor. Once devs realize they need it, and that they can get paid for it, 6 years of 16 hour days to acquire the knowledge looks pretty reasonable. Given that most compensation becomes bonus at some level, teams bifurcate into the long-hours, high-skill groups, and the shorter-hours, less-skilled people, with seniority, per se, accounting for little.
Posted by: gorobei at Dec 24, 2009 10:12:04 AM
Another thing is that programming attracts a lot of people who like computers and gadgets but who just aren't that great at math or logic in general. A great programmer has a lot of training but he also has innate logical ability, which is difficult to measure. A poor programmer may have the same amount of training, but if he's not good at logic puzzles then he should probably get another job. Unfortunately there probably aren't enough signals (e.g. low pay) to push him to do so.
Posted by: f at Dec 24, 2009 10:15:09 AM
"I think one of the reasons why this happens is because 90% of the cost of developing code is spent maintaining that code after it's already been written."
Studies have shown it's about 67%, but of course I agree completely with your point. Actually writing code is remarkably only about 3% of the cost of developing software.
There's a pie chart in this blog article of mine that shows the results from a couple of studies. The data is old enough that things may have changed, though.
http://coverclock.blogspot.com/2006/05/total-cost-of-code-ownership.html
Here's another blog article of mine (probably a little long) that talks about the tradeoffs of Time To Market (TTM) versus Cost Of Goods Sold (COGS) in software development.
http://coverclock.blogspot.com/2007/07/irresistable-force-and-unmovable-object.html
Posted by: Chip Overclock at Dec 24, 2009 10:19:41 AM
When I have done development work (either design or actual code), I have always compared my work against the company's bottom line. Did what I have just implemented impact positively the bottom line. If so how much? For example, on one job - I designed the data in such a way, that a CPU intenstive process could work the same database - completelely in parallel - with no data contentions, this allowed the system to run in nearly half the time (We split the work over two CPUs). This saved the company from paying IBM for more CPU capabilities on their machine.
Regardless of the work, I always asked the question, how does this effort help the organization? When I know the answer - I proceed, otherwise - I look for more productive uses of the time.
Now, I consider myself only a fair developer. It is not my passion. How should I be compensated? With the amount agreed upon between me and my employer. Everything else, including how much other people are getting paid is irrelevant.
Posted by: Michael at Dec 24, 2009 10:52:38 AM
I think the most likely explanation is that paying professionals on a piecework basis is inefficient. See Bob Sutton, recent TED talk by Dan Pink, etc., pretty much all the research says that for complex work, direct financial incentives reduce intrinsic enjoyment and productivity.
There are of course financial rewards for better performance but they tend to go over longer time horizons and come attached to promotions and such. But most of the rewards are nonmonetary--more respect and more autonomy.
Posted by: Dave at Dec 24, 2009 10:53:43 AM
This is also true to systems administrators. There is a significant difference between the 'good' engineers and the 'bad' engineers - but the productivity output doesn't look much different and the salary differences are relatively small.
As a manager of an IT department I have thought about this quite a bit. What I have concluded is that there is a substantial amount of non-wage compensation, especially in reputation.
The 'good' engineers (and developers) typically get:
1. More interesting projects.
2. Their pick of projects.
3. Wide latitude in deciding how their projects are designed and implemented.
4. Are highly sought out for opinions outside their core job role.
5. Quite a bit of discretion in working on unofficial projects (skunk-works).
Posted by: Chris at Dec 24, 2009 11:25:57 AM
It might be fruitful to consider how these programmers are selected in the first place. Unlike other fields that use traditional credentials, IT often uses certifications. Perhaps certifications provide stronger signaling value relative to more traditional credentials when it comes to on-the-job competence, but weaker value in signaling the distribution of ability.
Posted by: Abhi Sivasailam at Dec 24, 2009 12:05:10 PM
