What is the time it takes you to write a line of code?

Question

My manager said to me recently he thinks a developer can write 1 line of code every 6 minutes.

Jeff Atwood said in the podcast as he has gotten older he writes less lines, but thinks about what is writing so it is done better.

My question to the community is how long does it take you to write a line of code?

Do you find more often thinking before writing a line of code?

---

EDIT:

Please note that my manager is not measuring my productivity on the lines of code per hour/day/week etc. He is using it as an example to non-developers e.g. business side, about how long it takes to develop a product or feature.

It is being used to let the business side knows that software is not magically created, and not to delay on answers to questions because it will delay the final product.

Answer 1

If your manager is measuring coding in this way he has absolutely no idea what is going on. Look for another job.

The better you get at writing code, very often you will spend less time actually writing code and more time thinking about things from a higher perspective.

It is shameful that programmers were once paid or evaluated based on # of lines of code written.

Answer 2

Let's see...

a = 1;

I make that about about 2 seconds, max.

Answer 3

I'm lucky I rewrote an application to use 10% as much code as the previous developer and the application works significantly better. Since then SLOC has been laughed at and ignored as a metric.

Answer 4

Not very long, though I typically don't test things when I write code the first time through.

Answer 5

I think that if you are writing a tested line of code, using external libs and design patterns the time might be bigger than a well written one.

Code should be tested, if done by automated testing it's better. Also if done in an elegant way and tested through unit tests the better.

But all this makes you write less code, because you can solve your problem with fewer code, so that means less bugs, less maintenance costs, etc.

After all it is a broken metric

Answer 6

I would agree to a point about writing a line of code every 6 minutes. It depends on what the definition means. In order to make a production quality code I might have to test different ideas before I settle on a final correct approach.

The better measurement is how long does it take you to write a method. A good method should be fully understood before it is written. That discovery can take time (the better I know the code base the less time). Once I write the good method it of just 10 lines could of taken me 2 hours for some 2 minutes for others and even days.

There are days when I crank out a bunch of lines of code, could be a hundred an hour. There are other days when I only crank out 10 for the entire day. Some days I write 0 code. It depends on the complexity of the problem and my understanding of it. When you look at the aggregate of the week/project including design time testing, etc. . . a 1 line for every 6 minutes seems very likely.

Answer 7

Development requires a good deal of research and planning (read "time"). When you get around to writing code, even though you might actually not spend much time typing, that figure of 6 minutes per line isn't far off.

Answer 8

I recently worked out (in a very quiet moment) that I averaged about 37 lines / day roughly 12 mins/line) over the last 9 months. Doesn't sound a lot, but take thinking time, meetings, requirement discussions, etc. into account it is pretty reasonable.

More lines of code produced != better quality product.

Answer 9

That's like asking a carpenter how long it takes him to hammer in a nail. Probably not very long, really... But choosing the right nail and placing it in the right spot that makes all the difference.

Answer 10

To give an accurate answer appropriate for the question:

Coding rate varies between 0 and infinity in a ratio roughly equivalent to the complexity of the problem being solved and how well the brain is working.

Answer 11

I find about a factor of 1 to 100 in code writing speed for larger programs. A line of code every 6 minutes fits with a web app where I need to spend 10% of time in meetings with the customer, 20% writing down requirements and handling feedback on them, 20% finding out how to handle technical issues. Writing a parser for a known language can be done 20 times faster, a project where the customer doesn't want to make decisions and no one knows how (and why) the existing code is structured was at least 5 times slower.

Answer 12

It depends on the line of code. How long does it take you to type a sentence? How many sentences are in a good essay? A good book?

Answer 13

See the article "Measuring Testers by Test Metrics Doesn't" by Larry Osterman.

I think it depends on what your manager is planning to do with this productivity measurement. Is he going to penalize developers who don't meet or exceed the number, or is he just musing out loud about an average coding rate he has observed in past projects?

But I can understand that the way he phrased it, it sounds like he's running a sweatshop.

It's a false metric, as most people on this thread have pointed out. There are many important development activities that do not generate new lines of code very quickly. Debugging is a good example. A given bug may be very stubborn and require days of analysis, even though the fix ends up being very small and subtle. Yet those days could be very well spent.

Answer 14

A number of years back the standard was 10 lines of debugged / production ready code per day. Even with the latest drag / drop tools I don't think that has changed too much.

Between debugging, refactoring, meetings, throw away coding, etc it sounds about right. My guess is that it's probably closer to 30 or 40 lines now; excluding auto generated code.

Answer 15

In my last job, I refactored out so much code (Extract Method is my FRIEND) that even with the new features I wrote, I ended up causing a net reduction in the size of the code base. This project looks like it'll turn out the same way.

So, it takes me NEGATIVE six seconds to write a line of code. Or something.

Answer 16

The answer to this kind of question is always: it depends.

It depends on the programming language, on type of project you are working on, on the size of it, on your development process, on the skill of developers, etc.

The best you can do, is to measure, how long does it actually take in your company and in your project to write one line of code. Just count the lines in your project and divide it by the time spent developing these, and you will find out if your manager was right or wrong.

Answer 17

I think you manager should use a better example. One I've heard is programming is like writing a book. You do not measure a book by how fast the words are written. You judge it by the overal content (features). Some sections are short and easy to write, others are long and hard. It allows non-developer to relate, they should understand about common writing issues, such as writers-block (tireness/lack of ideas), a loosely defined subject (poor requirements). It should also allow them to understand how to keep a project going. Of cause the metaphor is not perfect, but it gives a good idea.

Answer 18

Let's say you can accurately predict the time it takes to write a line of code. You can't as many other answers here point out. However, let's assuem you could. How would that help you predict how long the project would take? How do you know how many lines of code the final project will take? Developers are terrible at predicting how long something will take (6-8 weeks?). They are even worse at estimating how many lines of code.

Answer 19

Let's see. If the line is short it takes me about:

 int i = 0;

1 to 1.6 seconds.

If the line is long...

public static void main( String [] args ) {

Oops... about 6 - 10 seconds.

For longer lines, I'm sure it would take longer.

Answer 20

It's a useless metric. I may write a short function to do a complex task in 20 SLOC. The amount of comments I have to add to describe any assumptions, tweaks, whatever are going to dwarf that. This is particularly true when I need to document the black-box (inputs, outputs, limitations, return values, error conditions, etc).

So, I may have written 20 source lines, but there could be just as much in doxygen blocks and inline comments so the next dev can actually figure out why it's done that way. All of that commenting takes time to write.

It's worse when you're modifying existing code because it could take a day to work out that something as simple as pre-increment should have been post-increment in a loop variable then prove that changing it won't break assumptions in the rest of the code. I've only "written" one line of code, but it took 8 hours to do it.

Answer 21

I read somewhere that the most productive programmers (whatever that means) write about 70 lines of code per day that will actually stay in the code base. So one line per 6 minutes should be way to much.

Answer 22

It depends a lot on what you are writing. This little gem took me more than a day:

public static double pow(final double a, final double b) {
    final int x = (int) (Double.doubleToLongBits(a) >> 32);
    final int y = (int) (b * (x - 1072632447) + 1072632447);
    return Double.longBitsToDouble(((long) y) << 32);
}

This also includes about 100 lines of comments and a unit test, it is an approximation for pow using floating point tricks. More info here.

The other extreme, when doing something simple and straightforward, typing speed is the limiting factor.

And even better, when refactoring it is always really cool when you can restructure the code and remove lots of stuff, and it still does the same as before :-)