Hacker News Reader

Comment by DaniFong | Hacker News Reader

I'm pretty sure this is false. Hackers such as Guido van Rossum or Linus Torvalds or Bill Joy are many orders of magnitude more productive than average programmers. Some of the old IBM studies cited in Peopleware show the average programmer writing 3 lines of code a day! PG mentioned that Trevor Blackwell rewrote their entire system in smalltalk in two weeks, which was everything that he and rtm wrote in 6 weeks. That's like an order of magnitude difference.. He and RTM were themselves probably an order of magnitude more productive than their competitors, with fourteen times the number of programmers and a worse product. And since those competitors were actually shipping products, they were probably an order of magnitude more productive than the average programmer working on internal tools at some BigCo, ekeing out 3 lines of buggy, ineffective code per day.

View on HN

Although I'd agree with the second part (that PG and RTM were exceptionally more productive than the Joe Schmoe the programmer), I don't think the Trevor Blackwell example is a good one.

I think it's routine for me, and most anyone, to write a first version of a system over a week or two and keep noticing ways the design could be improved. Over time cruft accumulates--and you continue to notice new problems you didn't anticipate when you first designed--and almost always it is much quicker to rewrite a second version than the first.

The 3 lines of code per day metric seems fishy to me, but it seems to be based on systems level projects (lets build a new operating system) rather than making a new PHP photoalbum for Grandma. It would be very interesting to see numbers which broke down LOC/day for different subsets of programming jobs.

I agree. The first write of anything is working things out. Feeling your way, experimenting, designing and iterating.

A "Complete rewrite" sounds hard, and like a big task, but usually it's a simple operation of copying existing functionality.

In my experience it's completely possible to spend 6 months writing version 1, and then completely rewrite it in a week.

> In my experience it's completely possible to spend 6 months writing version 1, and then completely rewrite it in a week.

I'll bet Netscape wished you worked for them in 1997.

I think quite often, rewrites are best done by 1 or maybe 2 people. I'm not sure they scale well to more.

I believe the studies you are referring to measured 3 lines of shipping code produced per programmer-day. This doesn't mean that Joe the Hacker went to his terminal and only typed three lines; it means that other people re-wrote code, or he spent a lot of time debugging something that was a short fix, or that a lot of programmer time was devoted to projects that were never shipped.

I'm not trying to defend mediocre programmers here, but I think you've misinterpreted a study that intentionally combines individual productivity with organizational productivity.

* Unfortunately, I wasn't able to find the actual study report. If someone can locate it I'd appreciate it.

I wasn't about to find the original report either, so I could be mistaken in this way.

Measuring things this way is completely wrong. All lines are not created equal. Finding a bug in 10 million lines of legacy code might take me a week to do a 2 line fix, whereas I have days where I can bang out 2-3k of mindless interface code. Sometimes I spend 2 weeks doing research to write a few hundred lines of code.

I find this sort of rhetoric honestly reeks of inexperience. Lines is a horrible metric for measuring productivity. Speed for finishing something isn't a particularly good metric either, since I've met a lot of hackers that can go on a coding binge (myself included) and accomplish as much in a weekend as they could in a couple of normal reasonably productive weeks.

IIRC, one of the major results of the Ericcson language studies (see for example http://www.erlang.se/publications/Ulf_Wiger.pdf) was that the lines of code metric was more or less constant over projects and across languages.

"Comparisons between Ericsson-internal development projects indicate similar line/hour productivity, including all phases of software development, rather independently of which language (Erlang, PLEX, C, C++ or Java) was used. What differentiates the different languages then becomes source code volume."

Do you have a better metric? How about skill in solving tough algorithmic problems which haven't been before solved? Often on, for example, TopCoder, the top competitor can solve a set of three problems in 15 - 30 minutes. The median competitor, even in the upper division, solves zero. Some of the problems at only the 'medium-level' in those sets are in fact so difficult that they are given as two-week assignments in university courses, and only a fraction of students can complete it. This doesn't seem like a difference in reliability and bug count, it seems like a difference in kind in both algorithmic ability and productivity.

They're trying to prove a very different point in that study; notably that for developers working on distributed architectures that it's faster to solve most problems with Erlang than C++. That's a very different sort of conclusion than saying that the best programmers write the most code.

I think the only reasonable metric is someone's portfolio. You wouldn't pick an architect by how many nails they'd used or a musician by how many notes they'd written. You have to look at what they've actually done.

And in fact, that's pretty close to what good hiring is about. You then see if real performance matches up to what's in the portfolio.

A vaguely tangential story, I was on-call during Y2K and I got called, but it wasn't urgent, and I stopped by the office on my way home from the party and fixed it.

For being on call at that time, I got a week's time in lieu and #500. For getting called, I got the same again. The fix was 10 lines of code, and the day after that I took it out and replaced it with a change to the original line.

Knowing what line of code: priceless :-)

PG mentioned that Trevor Blackwell rewrote their entire system in smalltalk in two weeks, which was everything that he and rtm wrote in 6 weeks. That's like an order of magnitude difference..

I don't know about that situation, but in general, rewriting a system is much easier than writing it in the first place.

What you wrote does not disagree with the author. He comes to the same conclusion: some developers are much more, even an order of magnitude more, productive than others.

He doesn't get to his real question until the last few paragraphs, which is why don't we see the same pay disparity with developers that we do with other professions? His answer is that measuring who's better is difficult and unreliable.

I admit I was confused, too; since he spends so much time on the issue of are some programmers orders of magnitude better than others, I thought that's what he was questioning. He doesn't get to his real question until the end, and then his answer is weak.

The author suggests that programmers vary in talent by reliability, buglessness, extensibility and maintainability. He goes on to suggest that these are hard to measure.

"It's not that good developers can churn out 10 times as many features as the bad ones. It's rather that good developers write code that have less bugs, more extensible and more maintainable. These are the things that you can't measure by statistics or figures."

I've given a few examples of good developers making systems that are orders of magnitude harder to complete, in the same time. In many cases it's not within the current talents of most programmers to write those systems at all. Another good example is the Quake engines. Additionally, in programming contests or student assignments there are many examples of people completing the same task in vastly different amounts of time. Finally, he states that reliability, buglessness, maintainability and extensibility are things you can measure with statistics, but many people have quantified uptime, maintenance, density-of-bugs, and extension time, to moderate success.

I'm not sure that's a valid measure of productivity. In a commercial setting most of the code is actually pretty straightforward, but it might take a day of meetings to agree with everyone that (for example) this is how interest should be calculated on this particular financial instrument. Been there, done that.

Also 3 lines of APL are a very different beast to 3 (or even 300) lines of COBOL...

Absolutely. The frightening thing is that average programmers on COBOL project seemed to still turn out ~3 lines of COBOL a day.

Reply on news.ycombinator.com