28 ms·

<blockquote>"We live in a world where the average developer writes 3,250 lines of code per year (about 20 per day). This is going into Eclipse, pressing the "g

<blockquote>"We live in a world where the average developer writes 3,250 lines of code per year (about 20 per day). This is going into Eclipse, pressing the "give me pattern X" and filling in the blanks, then going to a few meeting and calling it a day.</blockquote> Maybe I'm out of the loop, but is it really this bad out there in the real world?

crenshaw 15y ago
I think that's an exaggeration. In the real world you spend a week trying to track down a nasty bug -- the net result is two new lines of code in a week. Or writing a bunch of new tests or creating a new test harness. Or designing new features. Or figuring out a way to rearchitect your code to add a new feature in a way such that any new similar features don't require code change at all. I thought we had gotten past LoC as a measure of programmer productivity?
- outworlder 15y ago
  We have. But we still have to write something, don't we?
  - michaelochurch 15y ago
    Sure, but there's an order of magnitude difference in average difficulty (at least) per LoC in legacy maintenance vs. green-field development, and most software jobs are in the former camp. It's true that 20-40 LoC/day is a fast clip in most of the software industry; it's not true that this results from laziness or too many meetings. Hacker News gives us a rose-colored view of the software industry-- one in which knowing about functional programming and agile methodologies (regardless of whether one intends to use them) is a prerequisite for being considered literate, and in which 200 line-per-day development on new invention is something people can actually get paid for. That's now how the average developer experiences software.
  - SoftwareMaven 15y ago
    If what you are measuring doesn't give you data you can really make decisions with, it is worse than no data. You'll be tempted to make a decision because you have that data. BTW, this is one of my startup rules: measure what's important. Decide what's important by how it would affect your decision-making.
super_mario 15y ago
That has not been my experience. I just wrote a script to compute my stats for the last 10 years. I did roughly 20,000 lines of code per year (this is not counting comments and empty lines, if that is included then this goes up to 35,000 lines). Oh, and I prefer VIM to Eclipse :D. But using LOC as a measure of work quality or suitability for learning another language is really ludicrous. I would really hope that most people in the industry and Java programmers in particular are capable of learning Scala. I like to think that suitability of the language for a task is a quality of a language not the programmer. Yes, all languages in use are Turing complete, but some are better suited for certain tasks. The question we should be asking is what kinds of projects Scala excels at, and what kinds of applications is it really good for?
- outworlder 15y ago
  > Oh, and I prefer VIM to Eclipse And yet think you are part of the group mentioned by the article?
srparish 15y ago
Assuming lines of code is a valid argument, all the more reason to make sure those lines are doing as much as possible.
eengbrec 15y ago
I would say in many places it is, but the numbers are often misleading. I'm not completely familiar with how we count it, but I believe when we count ELOCs (Effective Lines of Code) not only is the time people spend writing code counted, or even all the time spent by people who write code, but all the time by people spend on the "software engineering" portion of the project. That can include managers, requirements development, configuration managers, system administrators, QA, the people who collect metrics, etc. So the number is really more reflective of how much an organization lumps under "software engineering" and how much general overhead its processes incur than it is of the productivity of individual programmers.
barrkel 15y ago
Yes. In one particular business domain: much of the time is spent nailing down requirements, then adjusting very complex conditionals (so much of the business-spec requirements will be almost legalese nests of conditional clauses - in the insurance domain I have in mind, written by actuaries), tweaking UI, and fairly exhaustive testing.
outworlder 15y ago
Yes. However, that depends on who you ask. Specifically, try banks (and other financial institutions), Fortune 500 companies (exclude the more tech savvy such as Google, Microsoft as the code that does get written is meaningful), and anywhere that is infested with suits. And, by the way: I believe that, out of the 20, 15 are XML.
freshhawk 15y ago
Absolutely. I took some high paying contractor gigs through an agency a few years ago because I wanted to figure out what direction to take in the next phase of my career, the cash was great and I'd never worked in the fortune 500 / government contractor kind of space before. I wasn't that surprised when I got told that I was now their second developer (out of a few dozen) who "actually writes code in his free time sometimes! isn't that crazy!" since I was prepared for big company suit world. The reality was right in line with the quote, if not worse.
- fadzlan 15y ago
  This kinda remind me of a lunch that I have with an old friend. I was asking him (he works at a fairly large company) if he knows anybody who learns or codes stuff that is outside of their working area, and his answer is, possibly in the whole building that he works, there isn't another one. Myself being a optimist, I don't believe that statement, there is probably someone. It has to be. Then again it could just be my wishful thinking.
  - freshhawk 15y ago
    I've started to think that it is wishful thinking. That was a big realization from that experience, that my echo chamber of programming sites and blogs and friends was not representative of programmers as a whole at all. I also saw the appeal of that side of the industry. These guys all had way more varied hobbies and family lives since the programming stuff is "just my job" and had a good stable career path because any motivation we in the hacker news crowd would spend on learning new cool stuff they spend on jockying for position in the big office social/political world. The lure of the office drone never got me though, it was too obvious to me that you are just selling the best part of your day for most of the week during the best part of your life only for money, since the actual hours are spent doing something you are marginally competent at and find uninspiring.
michaelochurch 15y ago
It's not about meetings, incompetence, or lax work hours. It's the reality of software maintenance. Lines of code is an awful metric of productivity but, yes, that figure of 3250 is accurate. Between 1,000 and 10,000 LoC per year is normal for a software engineer in the industry, and the rate is often closer to the lower number. Note also that code of average architectural quality will require about 1 maintenance day per year per 80 LoC just by virtue (vice?) of existing. (Paul Graham: a full-time maintenance engineer can own 20,000 lines of code.) LoC are a cost: if we rate a developer's time (including benefits, office space, etc.) at $80/hour and charge each LoC for 4 years, we pay $32 per line of code in maintenance. (We spend $2-3 per line to write it.) That is, IMO, a pretty accurate estimate of what we pay for software. If you write at 500 LoC/day under ideal circumstances but you're writing code that's merely average in architectural integrity, the maintenance problem will catch up with you very quickly. It's a lot better to write 150 lines per day of great code (200-300 including unit tests and debugging utilities) and maintain that pace than to start out at 500+ but stall out late in the project. Great programmers don't write code at college-project speeds; they write in such a way that they can sustain triple-digits in perpetuity. A single developer solves this problem by refactoring the code when necessary and incrementally improving the architecture so as to reduce the maintenance cost. It's only by doing this that projects beyond about 15,000 lines of code per person (75% maintenance burden if code is of average quality) are even feasible. It's not just a problem of incompetent developers. Maintenance imposes a 70 to 90% overhead on most important projects in large companies, just because these projects become difficult or impossible to refactor and fix and their "broken windows" patterns of decline take on a life of their own. Individual developers can refactor aggressively when their maintenance burden breaks 50% (70% being a crisis) but this is not usually feasible for multi-developer enterprise projects that have changed hands several times. The more progressive large companies now actively discourage any mention of LoC in performance reviews. First, deleting unnecessary code is one of the best things a person can do for a code base. Second, if someone in a big company generates 250 LoC/day reliably over years, it doesn't always mean that person is a great programmer; it could mean that, or it could mean that he's always taking the fun, "green field" projects and passing the legacy maintenance (on which 10 LoC/day is a typical clip) to others.
- vorg 15y ago
vorg 15y ago
When the programmers in these places take over the hiring process, they actively keep out anyone who can code better than average to protect their jobs. Many banks and insurance companies IT shops fall into this category.

crenshaw 15y ago

I think that's an exaggeration. In the real world you spend a week trying to track down a nasty bug -- the net result is two new lines of code in a week. Or writing a bunch of new tests or creating a new test harness. Or designing new features. Or figuring out a way to rearchitect your code to add a new feature in a way such that any new similar features don't require code change at all. I thought we had gotten past LoC as a measure of programmer productivity?

outworlder 15y ago
We have. But we still have to write something, don't we?
- michaelochurch 15y ago
  Sure, but there's an order of magnitude difference in average difficulty (at least) per LoC in legacy maintenance vs. green-field development, and most software jobs are in the former camp. It's true that 20-40 LoC/day is a fast clip in most of the software industry; it's not true that this results from laziness or too many meetings. Hacker News gives us a rose-colored view of the software industry-- one in which knowing about functional programming and agile methodologies (regardless of whether one intends to use them) is a prerequisite for being considered literate, and in which 200 line-per-day development on new invention is something people can actually get paid for. That's now how the average developer experiences software.
- SoftwareMaven 15y ago
  If what you are measuring doesn't give you data you can really make decisions with, it is worse than no data. You'll be tempted to make a decision because you have that data. BTW, this is one of my startup rules: measure what's important. Decide what's important by how it would affect your decision-making.

super_mario 15y ago

That has not been my experience. I just wrote a script to compute my stats for the last 10 years. I did roughly 20,000 lines of code per year (this is not counting comments and empty lines, if that is included then this goes up to 35,000 lines). Oh, and I prefer VIM to Eclipse :D. But using LOC as a measure of work quality or suitability for learning another language is really ludicrous. I would really hope that most people in the industry and Java programmers in particular are capable of learning Scala. I like to think that suitability of the language for a task is a quality of a language not the programmer. Yes, all languages in use are Turing complete, but some are better suited for certain tasks. The question we should be asking is what kinds of projects Scala excels at, and what kinds of applications is it really good for?

outworlder 15y ago
> Oh, and I prefer VIM to Eclipse And yet think you are part of the group mentioned by the article?

srparish 15y ago

Assuming lines of code is a valid argument, all the more reason to make sure those lines are doing as much as possible.

eengbrec 15y ago

I would say in many places it is, but the numbers are often misleading. I'm not completely familiar with how we count it, but I believe when we count ELOCs (Effective Lines of Code) not only is the time people spend writing code counted, or even all the time spent by people who write code, but all the time by people spend on the "software engineering" portion of the project. That can include managers, requirements development, configuration managers, system administrators, QA, the people who collect metrics, etc. So the number is really more reflective of how much an organization lumps under "software engineering" and how much general overhead its processes incur than it is of the productivity of individual programmers.

barrkel 15y ago

Yes. In one particular business domain: much of the time is spent nailing down requirements, then adjusting very complex conditionals (so much of the business-spec requirements will be almost legalese nests of conditional clauses - in the insurance domain I have in mind, written by actuaries), tweaking UI, and fairly exhaustive testing.

outworlder 15y ago

Yes. However, that depends on who you ask. Specifically, try banks (and other financial institutions), Fortune 500 companies (exclude the more tech savvy such as Google, Microsoft as the code that does get written is meaningful), and anywhere that is infested with suits. And, by the way: I believe that, out of the 20, 15 are XML.

freshhawk 15y ago

Absolutely. I took some high paying contractor gigs through an agency a few years ago because I wanted to figure out what direction to take in the next phase of my career, the cash was great and I'd never worked in the fortune 500 / government contractor kind of space before. I wasn't that surprised when I got told that I was now their second developer (out of a few dozen) who "actually writes code in his free time sometimes! isn't that crazy!" since I was prepared for big company suit world. The reality was right in line with the quote, if not worse.

fadzlan 15y ago
This kinda remind me of a lunch that I have with an old friend. I was asking him (he works at a fairly large company) if he knows anybody who learns or codes stuff that is outside of their working area, and his answer is, possibly in the whole building that he works, there isn't another one. Myself being a optimist, I don't believe that statement, there is probably someone. It has to be. Then again it could just be my wishful thinking.
- freshhawk 15y ago
  I've started to think that it is wishful thinking. That was a big realization from that experience, that my echo chamber of programming sites and blogs and friends was not representative of programmers as a whole at all. I also saw the appeal of that side of the industry. These guys all had way more varied hobbies and family lives since the programming stuff is "just my job" and had a good stable career path because any motivation we in the hacker news crowd would spend on learning new cool stuff they spend on jockying for position in the big office social/political world. The lure of the office drone never got me though, it was too obvious to me that you are just selling the best part of your day for most of the week during the best part of your life only for money, since the actual hours are spent doing something you are marginally competent at and find uninspiring.

michaelochurch 15y ago

It's not about meetings, incompetence, or lax work hours. It's the reality of software maintenance. Lines of code is an awful metric of productivity but, yes, that figure of 3250 is accurate. Between 1,000 and 10,000 LoC per year is normal for a software engineer in the industry, and the rate is often closer to the lower number. Note also that code of average architectural quality will require about 1 maintenance day per year per 80 LoC just by virtue (vice?) of existing. (Paul Graham: a full-time maintenance engineer can own 20,000 lines of code.) LoC are a cost: if we rate a developer's time (including benefits, office space, etc.) at $80/hour and charge each LoC for 4 years, we pay $32 per line of code in maintenance. (We spend $2-3 per line to write it.) That is, IMO, a pretty accurate estimate of what we pay for software. If you write at 500 LoC/day under ideal circumstances but you're writing code that's merely average in architectural integrity, the maintenance problem will catch up with you very quickly. It's a lot better to write 150 lines per day of great code (200-300 including unit tests and debugging utilities) and maintain that pace than to start out at 500+ but stall out late in the project. Great programmers don't write code at college-project speeds; they write in such a way that they can sustain triple-digits in perpetuity. A single developer solves this problem by refactoring the code when necessary and incrementally improving the architecture so as to reduce the maintenance cost. It's only by doing this that projects beyond about 15,000 lines of code per person (75% maintenance burden if code is of average quality) are even feasible. It's not just a problem of incompetent developers. Maintenance imposes a 70 to 90% overhead on most important projects in large companies, just because these projects become difficult or impossible to refactor and fix and their "broken windows" patterns of decline take on a life of their own. Individual developers can refactor aggressively when their maintenance burden breaks 50% (70% being a crisis) but this is not usually feasible for multi-developer enterprise projects that have changed hands several times. The more progressive large companies now actively discourage any mention of LoC in performance reviews. First, deleting unnecessary code is one of the best things a person can do for a code base. Second, if someone in a big company generates 250 LoC/day reliably over years, it doesn't always mean that person is a great programmer; it could mean that, or it could mean that he's always taking the fun, "green field" projects and passing the legacy maintenance (on which 10 LoC/day is a typical clip) to others.

vorg 15y ago

vorg 15y ago

When the programmers in these places take over the hiring process, they actively keep out anyone who can code better than average to protect their jobs. Many banks and insurance companies IT shops fall into this category.