• Create Account

# Lines of Coding Per Day

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

49 replies to this topic

### #21Bacterius  Crossbones+   -  Reputation: 9268

Like
0Likes
Like

Posted 10 January 2013 - 07:52 PM

A) One line of code in one language at a higher level of abstraction might be worth twenty in another language.
B) A poor programmer might write 10 lines of code when 5 might suffice (not properly re-factoring into functions), or a poor programmer might write 5 lines of code when 10 would be better (example: skipping error checking).
C) A poor programmer might write 50 lines of code, and have to re-write it later because the first time it was done wrong. Does that mean he wrote 100 lines of code, despite only 50 ending up in the final project?
D) "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

I like that analogy.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #22Hodgman  Moderators   -  Reputation: 31799

Like
3Likes
Like

Posted 10 January 2013 - 08:39 PM

Given that sometimes we write few lines in a day, what is the most that you guys have written in a full work day - assuming good code with few or no bugs and little at most debugging/rewriting?

I've never measured it, so I'm just making up numbers with no evidence*, but I would guess:

1000-3000 LOC/day == you're just typing all day without much thought

10-100 LOC/day == you're writing good code

*Your mileage will vary.

On average, even when not debugging, I don't write that many lines of code a day. Sometimes as low as 10, which leaves most of my time for thinking rather than typing.

Instead of banging out 1000 lines all day long to complete a task, you can probably think about it a little more and accomplish the same task with 100 lines (which is more valuable overall, because it makes maintenance easier in the long run).

My lowest LOC-per-day score was when I was assigned a random memory-corruption bug (which was actually caused by a buffer-overrun by the GPU, due to the VRAM allocator being buggy), which took over a month to figure out. After a month of debugging, the fix was 1 line of code, or about 1/20th of a line per day over that period  There was also more than one of us working on the bug, so maybe the real score is 1/50th LOC/day each!

Also, the amount of typing you'll do also depends on the kind of programming that you're doing. If you're building a new API then you'll spend a lot of time thinking about architecture, and very little actually writing the interface based on those thoughts. On the other hand, if you've got a tight deadline, e.g. "we need to show this level at E3 tomorrow!!", but that level in the game hasn't even been started yet, then you might hammer out 1000 lines of poorly written code to script that level's events, for now.

Edited by Hodgman, 10 January 2013 - 08:50 PM.

### #233Ddreamer  Crossbones+   -  Reputation: 3165

Like
0Likes
Like

Posted 10 January 2013 - 08:40 PM

How many lines of code you write isn't a good way to measure your coding ability!

LOL

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

by Clinton, 3Ddreamer

### #24Telastyn  Crossbones+   -  Reputation: 3730

Like
2Likes
Like

Posted 10 January 2013 - 10:07 PM

Code complete (iirc) has that study, though I remember it being 10 lines of code per day, per dev, on average.

In general, I can implement one straightforward feature with tests and documentation and team communication (meetings) in 4 hours. A mildly complex feature takes about a day.

### #25Ravyne  GDNet+   -  Reputation: 8138

Like
4Likes
Like

Posted 10 January 2013 - 10:23 PM

In the end, only two measurements matter:

Does my code do more useful stuff today than yesterday?

Am I more happy with my code today than I was yesterday?

As long as one of these things happen in the short term, and as long as both are happening on the long term, all is well.

### #26Mussi  Crossbones+   -  Reputation: 2097

Like
0Likes
Like

Posted 11 January 2013 - 08:05 AM

I'm following a software engineering course atm. Apparently the average lines of code that makes production is 14. This is not for the game industry specific though.

### #27Strewya  Members   -  Reputation: 1581

Like
0Likes
Like

Posted 11 January 2013 - 03:28 PM

i'll throw in a joke answer, and say the magic number is 42.

devstropo.blogspot.com - Random stuff about my gamedev hobby

### #28wintertime  Members   -  Reputation: 1867

Like
0Likes
Like

Posted 11 January 2013 - 05:12 PM

I agree LOC is a poor measurement.

Though I read somewhere if one really needs a number it should be written_lines+modified_lines+deleted_lines all counted positively to account for debugging and refactoring. Probably the people being measured should also not know cause they would skew those numbers then conciously or uncounciously.

### #29frob  Moderators   -  Reputation: 22714

Like
2Likes
Like

Posted 11 January 2013 - 05:27 PM

I've got my own internal unit of work.  I cannot explain it well, but I understand what it means. It is simply doing one thing completely.

It is similar to an agile or scrum task, and could easily be implemented as such.

To me one unit means doing one thing.  When I work on TDD code, I would measure it on the range of implementing 1 to 3 unit tests and the associated code.

My unit of work is often 10-30 lines of code.  Sometimes it is 50 or more.  Sometimes it is a net of zero lines.  Sometimes it is a negative number of lines.

Sometimes a unit of work is a little thing.  For example, if I need to change a string key, or modify some other minor variable, that unit is small.  Other times a unit is a bigger thing, such as implementing the boilerplate class for a new feature and making changes to the various files in the projects and documenting the creation; that is a bigger unit.  Hooking up an entire complex UI screen may be a full day task, and that is the biggest unit.

A unit is measured in hours, anywhere from 0.5 to 6.  Six hours means a full day, it still allows time for meetings, buddy-checks, down-time, general office work, and social stuff.  There is a minimum time of a half hour; if nothing else, it gives you plenty of time to test around the change before you submit.  Anything bigger than 6 is obviously more than one unit of work and must be broken down into smaller work units.

One unit of work is the thing that I submit into version control.  I don't submit a partial unit of work (because that would be an incomplete change) and I try not to include more than one unit of work, because a change should be just one atomic thing.

Now that you know what one unit of work is, I can say I strive to get around 3-5 units of work done each day, balancing between big tasks and little tasks.  Sometimes I manage to get ten or more of them done.  Sometimes I struggle to complete even a single unit.

I started following this pattern when I was introduced to scrum-style development in '99.  The ability to break tasks down this way was one of the things that transformed my abilities as a software developer.  Honing that skill means I can generate accurate estimates, and I can say with confidence how long an individual task would take me and what I plan to do to complete it.

Edited by frob, 11 January 2013 - 05:38 PM.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.

### #30Washu  Senior Moderators   -  Reputation: 5422

Like
0Likes
Like

Posted 11 January 2013 - 05:35 PM

Given that sometimes we write few lines in a day, what is the most that you guys have written in a full work day - assuming good code with few or no bugs and little at most debugging/rewriting?

I've never measured it, so I'm just making up numbers with no evidence*, but I would guess:
1000-3000 LOC/day == you're just typing all day without much thought
10-100 LOC/day == you're writing good code

*Your mileage will vary.

On average, even when not debugging, I don't write that many lines of code a day. Sometimes as low as 10, which leaves most of my time for thinking rather than typing.
Instead of banging out 1000 lines all day long to complete a task, you can probably think about it a little more and accomplish the same task with 100 lines (which is more valuable overall, because it makes maintenance easier in the long run).

My lowest LOC-per-day score was when I was assigned a random memory-corruption bug (which was actually caused by a buffer-overrun by the GPU, due to the VRAM allocator being buggy), which took over a month to figure out. After a month of debugging, the fix was 1 line of code, or about 1/20th of a line per day over that period  There was also more than one of us working on the bug, so maybe the real score is 1/50th LOC/day each!

I wrote 5 lines of code yesterday. Of those lines, 3 were a unit test, and 2 made the test pass.
A good manager, and a good team, will schedule the time each artifact should take, and then record how long it really took.

I have a piece of software that I wrote that helps me with scheduling my people. I keep track, in it, all of the various pieces of software we've written, the feature breakdown of the software, the time each feature took, who did it, my rough estimates of their skill levels... It lets me do lots of things, for instance... I can go into a company (I'm a consultant), sit down with their team of developers, interview them and get an idea of their skill level. Using the years of data I've acquired in my database I can then use it to produce reasonably accurate estimations of how long it will take to perform the work I've been contracted to do.

The more data you gather, the more pieces of information you have, the better and more consistently you can schedule your people, deadline dates, and releases.

Frankly, its more important to learn how to work WITH a developers skill level than the number of lines of code he writes in a day.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX

### #31swiftcoder  Senior Moderators   -  Reputation: 10364

Like
0Likes
Like

Posted 11 January 2013 - 05:36 PM

One unit of work is the thing that I submit into version control.

QFE.

Features and bug fixes committed to the source repository is the primary metric of progress. Sometimes you are committing a single-line bug fix, or a -20,000 line refactor, but at the end of the day, that is the progress everyone will see and care about.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]

### #323Ddreamer  Crossbones+   -  Reputation: 3165

Like
0Likes
Like

Posted 11 January 2013 - 06:33 PM

Interesting that I had been studying source repository, version control, and other areas related to SCM before I started this thread. I was wondering how to specifically report the work of programmers. It is really the underlying motivation for my starting this thread.

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

by Clinton, 3Ddreamer

### #33ApochPiQ  Moderators   -  Reputation: 16392

Like
0Likes
Like

Posted 11 January 2013 - 06:37 PM

Frankly, its more important to learn how to work WITH a developers skill level than the number of lines of code he writes in a day.

A billion times THIS.

Learning to capitalize on the strengths of your team members - and compensate for their weaknesses - is a soft skill. You don't do it by assigning numbers to things and making pretty charts. You do it exactly as Washu described: by gathering a lot of experience in how different people operate, and getting an intuitive sense for how to integrate the efforts of disparate workers.

Managers who exclusively use metrics to judge everything their teams do are a royal pain in the ass to work with. Good managers know how to use metrics to inform the much more subjective process of helping a team reach peak productivity.

Interesting that I had been studying source repository, version control, and other areas related to SCM before I started this thread. I was wondering how to specifically report the work of programmers. It is really the underlying motivation for my starting this thread.

You report the work of programmers in precisely one way:

Is the customer satisfied? Yes? Work's done. No? Get back to work.

Break this down into fine-grained tasks if you like (I personally think that makes sense) but in the end all other measurements are failures and will serve to annoy people far more than they will help.

Edited by ApochPiQ, 11 January 2013 - 06:38 PM.

Maker of Machinery

### #340Circle0  Members   -  Reputation: 343

Like
0Likes
Like

Posted 11 January 2013 - 06:45 PM

When I code I try for 1000 lines a day. That tends to tapper off the closer you get to the end. As long as you have direction your lines per day are limited by your typing speed and accuracy. Which play a large part in how fast you can code. Assuming you already know where you are going with that code.

Sprite Creator 3 VX & XP

WARNING: I edit my posts constantly.

### #35mhagain  Crossbones+   -  Reputation: 8276

Like
0Likes
Like

Posted 11 January 2013 - 06:48 PM

Lines of code is a very poor measurement tool for several reasons:

A) One line of code in one language at a higher level of abstraction might be worth twenty in another language.
B) A poor programmer might write 10 lines of code when 5 might suffice (not properly re-factoring into functions), or a poor programmer might write 5 lines of code when 10 would be better (example: skipping error checking).
C) A poor programmer might write 50 lines of code, and have to re-write it later because the first time it was done wrong. Does that mean he wrote 100 lines of code, despite only 50 ending up in the final project?
This, this, this, this, this. So many times.

Don't measure your (or anyone else's) productivity in lines of code - measure in objectives achieved. Did they get that post-processing effect written in a manner that fits well within the performance and resource-utilization budgets? If so, who gives a damn whether they did it in 5 lines of code or in 50,000 lines of code? It doesn't matter! If it's not nasty code, if it integrates well, if it meets the requirements, if it achieves the objective; they're far more valid metrics.

The fact that it's possible to sweat and agonize over 20 lines of code whereas it's also possible to grind out 20,000 lines of absolute garbage should clue you in - lines of code is not something you should be measuring. Forget it. Ignore it. Focus on the objectives, focus on what you're doing. Code is a means to an end, not an end in itself.

Edited by mhagain, 11 January 2013 - 06:50 PM.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #36Cornstalks  Crossbones+   -  Reputation: 6991

Like
1Likes
Like

Posted 11 January 2013 - 06:56 PM

I'm curious how many of the people who are suggesting >50 lines per day (averaged) have worked in a professional setting... And what kind of code they're writing...
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

### #373Ddreamer  Crossbones+   -  Reputation: 3165

Like
0Likes
Like

Posted 11 January 2013 - 07:01 PM

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

by Clinton, 3Ddreamer

### #38ApochPiQ  Moderators   -  Reputation: 16392

Like
4Likes
Like

Posted 11 January 2013 - 07:20 PM

I can't speak for Cornstalks, but here's my take:

In the real world, building software means many different things:
• Actually writing new code
• Reading existing code, either to inform the creation of new code, or to improve what already exists
• Talking about code with colleagues
• Working on documentation
• All the miscellaneous stuff that having a real job entails: meetings, reports, etc.
Especially if you are working on a product that's already in-use someplace, you don't just bang out reams of new code all day. Understanding and refining existing code is far more of a time sink than just typing new syntax into your IDE.

I spend only a fraction of my day actually in my IDE, and only a tiny fraction of that writing new code.

Even on my personal hobby projects, far more time goes into planning and maintenance than actually churning out squiggly symbols.

My gut feeling - and I suspect Cornstalks shares this sentiment - is that people who are (A) focused on LOC production and/or (B) talk about dozens or hundreds or thousands of LOC a day are doing something wrong.

Would you rather have a dentist who needs three hours to give you a root canal and a crown, or thirty seconds to rip out all your teeth and hand you a pair of dentures?

Edited by ApochPiQ, 11 January 2013 - 07:21 PM.

Maker of Machinery

### #393Ddreamer  Crossbones+   -  Reputation: 3165

Like
0Likes
Like

Posted 11 January 2013 - 07:26 PM

Apoch,

Have you ever gone over 100 in a day with good clean code, say using a scripting language of the simpler kind?

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

by Clinton, 3Ddreamer

### #40Cornstalks  Crossbones+   -  Reputation: 6991

Like
0Likes
Like

Posted 11 January 2013 - 07:35 PM

What ApochPiQ said (and what I previously said). Also, I'm sincerely curious (to a degree, though I'm afraid it might give me nightmares).

Also, I just want to clarify that I'm not suggesting you should never exceed X number of lines in a single day. I was (and am) talking about averages.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS