2 ms·

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

by wheels 18y ago

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.

DaniFong 18y ago
IIRC, one of the major results of the Ericcson language studies (see for example http://www.erlang.se/publications/Ulf_Wiger.pdf 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.
- wheels 18y ago
  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.
gaius 18y ago
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 :-)

by wheels 18y ago

DaniFong 18y ago

IIRC, one of the major results of the Ericcson language studies (see for example http://www.erlang.se/publications/Ulf_Wiger.pdf 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.

wheels 18y ago
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.

gaius 18y ago

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 :-)