Summary
How many software developers does it take to change a lightbulb? 10 to discuss the requirements, 10 more to do the analysis, 10 more to do the design, and one to write the code, 12 years later.
Advertisement
On a newsgroup recently someone said: "Half of all programmers are below average." I responded that that was not necessarily true. Certainly half are below the median, but it is remotely possible that only one programmer is above average. (I'll leave you to decide who I was thinking of.)
I said this flippantly, but I was partially serious. 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.)
OK, this is snobbery. I know it. And maybe my numbers are a little skewed. Perhaps it's not 90/10. Perhaps it's 80/20 or even 70/30. But it sure isn't 50/50!
I once consulted for a company that had 50 developers working on a simple GUI. This GUI was a flat panel touch screen upon which several dozen dialog boxes could be made to appear. These 50 developers worked on this project for five years or more. That's 25 man-decades, 2.5 man-centuries! COME ON! Three guys could have done this in three months! My buddies and I used to joke that they had one developer per pixel and that each developer wrote the code for his pixel.
OK, so the manager was empire building. Some managers measure their worth by the number of people they manage rather by how much they can get done with how little. Still, I find this problem is not isolated. It seems to me that a large fraction (perhaps a majority) of all software projects are overstaffed by a huge factor.
I wonder if we'd get a lot more done in this industry if 90% of us quit.
> I wonder if we'd get a lot more done in this industry if > 90% of us quit.
Oddly enough, this very idea came up as a serious notion at the Writing Better Code summit in Portland in January. We wondered if it would not help code quality and productivity on the whole by simply lopping off the bottom third of your programmers. One attendee, who I'm sure would want to remain unnamed, quipped: "Execute programmers, not code."
Unfortunately, I think your 90/10 spilt is a bit more accurate. This sort of reminds me of Sturgeon's Law: Ninety percent of everything is crap (see http://www.pragmaticprogrammer.com/ppllc/papers/1998_02.html). And this is exactly why I've rededicated myself to becoming a "Pragmatic Programmer." Either you are a part of the solution (those fighting for the 10%) or your job is about to be outsourced...
> Unfortunately, I think your 90/10 spilt is a bit more > accurate.
My experience also reinforces Sturgeon's Law. Various informal studies do as well (see an article on Jeff Sutherland's site to that effect). Certianly of the programmers I've met, only 10% are what I'd consider "good". My criteria being whether I'd want to work with them or hire them.
One thing to be careful about... skill and experience do not qualify one for that 10%... it's raw ability, talent, and atitude.
> ...Certainly half are below the > <i>median</i>... It > seems to me that 90% of the code that gets written in the > world is written by 10% of the programmers.
I don't know. I think a lot of bad code gets written by a lot of bad developers. Over and over and over.
There seems to be an implicit assumption that it is the developers' fault that they're developing bad code. In my experience, a lot more finger pointing needs to be done towards the way the developers are being managed.
Most developers will produce code to whatever standard is demanded of them. If the code being produced by the developers is not being properly monitored (specification adherance, coding standards, walk-throughs, unit tests, system tests, documentation, etc.) then it is a management failing for accepting whatever it is that is being produced. The developers will go on producing what they are being permitted to produce.
Replacing a single developer in a team may produce significant improvements - but only locally. Replacing a team leader can transform the quality and productivity of a whole team. Replaceing a project leader can transform the viability of a whole project, regardles of the qualities of the other individual in the project.
Developers are human beings and human beings are herd animals. They will naturally gravitate around - and adopt the qualities of - whatever leader is available. In the absence of a leader, development will still happen but a corporation only has itself to blame if it finds that what is being developed ins't what it expected.
I once took a project that had 10 programmers working on it for 18 months that was non-functional, and crashed after every transaction and re-wrote it entirely. The original had 28k lines of code. In 2 weeks I had written 14k lines of debugged code (with 2 others producing 1.5k). The software was shipped to customers within 6 weeks of my start date.
> In 2 weeks I had written 14k lines of debugged code (with 2 > others producing 1.5k). The software was shipped to > customers within 6 weeks of my start date.
I look at this and can't help thinking that it would have been better and done sooner if you were working in a pair.
Also.. how much time was spent "debugging"? What if you could have eliminated the time spent debugging and replaced it with time spent writing tests? Then the software wouldn't have simply been "debugged", it would have been tested, documented, and more maintainable.
> > In 2 weeks I had written 14k lines of debugged code > (with 2 > > others producing 1.5k). The software was shipped to > > customers within 6 weeks of my start date. > > I look at this and can't help thinking that it would have > been better and done sooner if you were working in a > pair. > > Also.. how much time was spent "debugging"? What if you > could have eliminated the time spent debugging and > replaced it with time spent writing tests? Then the > software wouldn't have simply been "debugged", it would > have been tested, documented, and more maintainable. > > Dave
Actually, by debugged, I meant fully tested, I can't recall any significant bugs in the QA step. Customer documentation was done by a separate group, that's why the final result came out in 6 weeks. To do this kind of work quickly required writing a complete framework, before writing the application. The only individual involved from the original group spent a couple of days writing a testing frame for us. Mind you, those were 2 90 hour weeks, not 40 hour weeks, as there was a contractual obligation with a big penalty to meet.
I think that I should add that the original problem that caused the project to fail on the first go-round was closely related to management's insistence on using a bad architecture, and an un-focused project leader.
To meet the extreme time requirement (during which all the guilty management were on vacation) I elected to keep the team size down to the absolute minimum required to get it done. By having only 3 individuals, and no members of the original team we could reduce communication bandwidth requirements between the team members.
I wasn't familiar with agile methods at the time, but I doubt whether they would have helped get the job done any faster.
I wonder if we'd get a lot more done in this industry if 90% of us quit.
I wonder if I can convince my boss to pay me to just stay home. Hell, I'd even take a pay cut; they'd save money and increase productivity! It's win-win all around.
Unless, of course, I'm in that top percent doing most of the work ...
OK, quick show of hands: how many here are in that top percent? How many think the other guy with his/her hand up is deluded?
>OK, quick show of hands: how many here are in that top percent? How many think the other guy with his/her hand up is deluded?
Of course, anybody reading Artima.com is in the top 10%!! :)
I say that jokingly, but there is some truth to it. As in any industry, the people who keep up with the latest ideas and concepts tend to be up there in that top 10%. It's definitely a chicken or egg thing of course..
Another thought: There's something to be said for the "take your top developers and stick them in a room with whiteboards" methodology. This methodology works (in effect) because you are increasing communication between the effective %10 and removing the burden of communication with the bottom 90%.
Yet another thought: Another thing that we can't forget are the qualities that make up that 10%. There are a lot of the 90% that could potentially be in that 10%, except they don't have the experience. Just because you write crappy code doesn't mean you can't eventually write beautiful code..
A lot of that 10% has had the opportunity to work with teams of other 10%ers. If you are a new developer and you work in teams composed of 90%ers, you are more likely to become a 90%er (more likely, not guaranteed). If you end up working on teams of 10%ers, you are more likely to get a one-way ticket into 10%-dom (more likely, not guaranteed).
Yet another thought: Another thing that we can't forget are the qualities that make up that 10%. There are a lot of the 90% that could potentially be in that 10%, except they don't have the experience. Just because you write crappy code doesn't mean you can't eventually write beautiful code..
A lot of that 10% has had the opportunity to work with teams of other 10%ers. If you are a new developer and you work in teams composed of 90%ers, you are more likely to become a 90%er (more likely, not guaranteed). If you end up working on teams of 10%ers, you are more likely to get a one-way ticket into 10%-dom (more likely, not guaranteed).
I have to agree with Javid's observation here. I'll be the first to admit that I've written some really crappy code in the past. In the past few years between being fortunate enough to work with some good developers, reading sites such as this and just doing as much as possible to keep abreast of new developments, ideas, etc. I've really seen a change in my coding.
I'm sure there is plenty I can still learn and I may have a way to go, but I know I've progressed a lot. I can tell just by the thoughts I had reading the pragmatic programmers interview. A few years ago I know I would have looked at most of what they were saying and thought "yeah, whatever". Now most of it makes sense to me. I won't say I agree with 100% of everything they say, but I can see where they are coming from when they say it. And most times that seems to make all the difference.
My personal observation is that as long as you've got the right attitude, you can learn the rest. Talent and smarts help (immeasurably in some cases), but if you wander through life thinking you know it all and aren't humble enough to think there's something new you can learn, you're doomed.
I bow before your 10%'edness and hope to join you some day.
Mind you, those were 2 90 hour weeks. So you're asking me to believe you produced almost eighty lines of debugged code per hour? Hmmm. It would be impolite to call you a liar, so you are clearly among the world's elite.
> Mind you, those were 2 90 hour weeks. So you're > asking me to believe you produced almost eighty lines > of debugged code per hour? Hmmm. It would be impolite > to call you a liar, so you are clearly among the world's > elite.
I am not asking you to believe anything. Nobody on this forum knows me, cares about what I have done, or has acknowledged my existence, up to this point. I am not getting an award for bragging rights. Please cut the flame, and waste of bandwidth.
I was merely trying to illustrate the validity of the premise of the original article.
The metrics were generated by the project manager for his own purposes. I don't know what he counted in LoC, maybe he included blank lines. I wasn't in a race to produce the most LoC, just a race to solve a problem with an extremely short deadline.
Flat View: This topic has 19 replies
on 2 pages
[
12
|
»
]
Previous Topic
