Regarding the difference in productivity of Developers (or Programmers/Coders if you prefer), there are two distinct opinions:
1/ big gap between mediocre developers and good developers (or good devs and great devs), some factors like 10x or even more (“Tenfinity factor”) .
2/ not much different , a software team can always replace ONE veteran by 3 newbies and still good to go.
.
Personally speaking, I totally agree with the first one. There are some articles which also defend the 1st, here are some quotes from them:
+ “The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1.”
(Steve McConnel – 10x Software Development)
.
+ “The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.”
(Joel Spolsky – Hitting the High Notes)
.
+ “It seems to me that 90% of the code that gets written in the world is written by 10% of the programmers. The other 90% of the programmers write the remaining 10% of the code (and the 10% then fix it.)”
(Robert C. Martin – One per Pixel)
.
+ “The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.”
(Robert L. Glass – Facts and Fallacies of Software Engineering)
.
+ “The general finding that “There are order-of-magnitude differences among programmers” has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).”
(Steve McConnel – The origins of 10x)
.
+ “It is an odd fact that is not reflected in salaries that a good programmer is more productive than 10 bad programmers. This creates a strange situation. It will often be true that you could move faster if your weak programmers would just get out of the way. If you did this you would in fact make more progress in the short term.”
(Robert L. Read – How to be a programmer)
.
+ “The difference between the extremes has been reported as high as 100:1. The closest these numbers ever seem to come to one another is about 4:1. But how much more does this extreme difference in value end up costing?
Assuming that your annual cost for the least competent developer is $50k, what are you paying your best developers? $80k? $120k? $150k? Since a lot of the costs for an employee are fixed, they don’t increase in relation to base salary. For the purposes of this examination, let’s use some worst-case figures, $150k. Assuming that your $50k developer delivers $50k of value (otherwise they’d be reallocated, right?). If your best developer is a mere four times more productive than the worst, they deliver value $50k in excess of their cost.”
(Daiv Russell – Hold On to Your Top Performers)
. . .
.
There is also the Dunning–Kruger effect, of course ;-) . I would like to link to some interesting posts in Vietnamese about it:
+ http://bloghoctap.com/bai-viet-khac/hieu-ung-dunning-kruger.html
+ http://buratinodl.wordpress.com/2011/10/12/thieu-nang-luc-va-hieu-ung-dunning-kruger/
+ http://forum.ipl.edu.vn/showthread.php?t=5776
+ http://www.dkons.vn/Bai-hoc-marketing-tu-chuong-trinh-American-Idol-59-dkons.html
That’s all. Any remaining is left as excercise for the readers :D .
./.
DucQuoc's Blog 
Pingback: Cognitive bias traps | DucQuoc's Blog
Bonus:
“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.”
(Bill Gates)
http://programmers.stackexchange.com/questions/110606/great-programmer-productivity-accounting-for-10-000-fold-difference
”
. . .
How can someone be 10x more productive than his peers without being noticed? In some professions such a difference would be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. Sales are easy to measure, and some salesmen make orders of magnitude more money than others. If a bricklayer were 10x more productive than his peers this would be obvious too, but it doesn’t happen: the best bricklayers cannot lay 10x as much brick as average bricklayers. 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.
. . .
”
http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity/
An excellent explanation is a short (simple) one but it can explains profound issues !
And, the *ultimate* value of a “uber” programmer is that not only he can solve the hard problem in short time (10x) , but also he can *raise the whole team’s productivity* (2x or 3x) , either by playing a supporting role (active), or making an exemplary result inadvertently (less active) .
Martin Fowler has a better explanation for productivity assessment:
“. . .
If team productivity is hard to figure out, it’s even harder to measure the contribution of individuals on that team. You can get a rough sense of a team’s output by looking at *how many features they deliver per iteration*. It’s a crude sense, but you can get a sense of whether a team’s speeding up, or a rough sense if one team is more productive than another. But individual contributions are much _harder_ to assess. While some people may be responsible for implementing features, others may play a supporting role – helping others to implement their features. Their contribution is that they are *raising the whole team’s productivity* – but it’s very hard to get a sense of their individual output unless you are a developer on that team.
. . .”
( http://martinfowler.com/bliki/CannotMeasureProductivity.html )
*A story about Khoa and Nam*
Khoa is a Rockstar. Khoa talks about all the latest trends at all the coolest conferences around the world. Khoa makes a point of starting each project with at least 18 design patterns and three new technologies. When asked to produce an internet-based backend for letting kitchen devices synchronize their list of recipes, Khoa went to town. The result was a combination of Google Protocol Buffers, node.js, and Cassandra, not to mention 22 design patterns out of 23 from GoF. Scalable, complex, and totally unmaintainable.
Nam is a good developer. Nam started as a Unix Admin, and moved into Ruby two years ago. When asked to produce the same system, he immediately started asking questions:
“How many devices do we expect to have?”
“Well, we hope to sell 500 in 12 months.”
“How often will they need to report in?”
“Roughly once an hour.”
“How reliable is the network?”
“It’ll use WiFi, so fairly reliable.”
Nam wrote a RESTful API endpoint in Rails with a MySQL DB. PostgreSQL would have been better, but he “knew mysql.”
Will Nam’s solution scale to 10k concurrent users? No, but it doesn’t need to. Nam’s solution is simple, easy to understand, and highly maintainable. Nam knew it wasn’t the most elegant solution, but he also knew that anything much more complex would be beyond his current skills. (which will negatively affects the business value and budget of the client)
well, the story above (Khoa & Nam) is my copy-cat from Tammer Saleh’s, just slightly modified.
Pingback: Ramp-up explained | DucQuoc's Blog
Pingback: Logging best practices | DucQuoc's Blog
Pingback: Personal Review 2012 | DucQuoc's Blog
Pingback: Sprint end DoW | DucQuoc's Blog
Pingback: Sprint end DoW | DucQuoc's Blog
Pingback: Dan ong 30 | DucQuoc's Blog
Pingback: Most view posts 2021 and prior | DucQuoc's Blog