• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
3Ddreamer

Lines of Coding Per Day

49 posts in this topic

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.
0

Share this post


Link to post
Share on other sites

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.laugh.png

0

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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 laugh.png 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.
Anyway, in the real world, good managers will adapt to your skill level and speed. I've always been assigned tasks and asked to estimate the time it will take me to complete them by myself (instead of being given the time-frame that the task will take by the manager). You and your manager will slowly learn how quickly you can complete certain types of features, they'll learn which parts of the game it's most useful for you to be working on, and your estimation skills will improve over time too. You'll improve at your own pace, and as you do, your new skills will be recognized with more responsibilities, bigger tasks, and hopefully, promotions cool.png
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.
0

Share this post


Link to post
Share on other sites

[quote name='frob' timestamp='1357946863' post='5020522']
One unit of work is the thing that I submit into version control.[/quote]

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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...
1

Share this post


Link to post
Share on other sites
Apoch,

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

Share this post


Link to post
Share on other sites
Please explain, Cornstalks. What is your experience with it?

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.

0

Share this post


Link to post
Share on other sites
Have I typed more than 100 lines of code in a day? Sure, no problem.

Have I ever been happy with shipped code that - after taking into account debugging, polish, refactoring, and documentation - was produced at that speed? Hell no.
1

Share this post


Link to post
Share on other sites

Considering what the others said, I felt that this quote sums it up quite well:

 

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight." 

-Bill Gates (Or so they say)

 

The number of lines of code and the efficiency of the code are quite often different.

 

Edit: Dang, Someone already posted that quote!  Well this will reinforce it's importance ;)

Edited by DeafTV
0

Share this post


Link to post
Share on other sites
Even if you received numbers from people it would be useless info.

It doesn't matter if you spend days to just change a single character in a single file, as long as the bug gets fixed.

In fact if you find yourself writing tons of code in a day then it's probably a bad sign, possibly in crunch mode.

Spend more time thinking and you'll end up writing less code that does the same job better.
0

Share this post


Link to post
Share on other sites
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 have, but my professional settings have perhaps been atypical. 2 greenfield projects, 3 projects involving machete refactoring that may have well been greenfield, and 1 job that largely involved writing disposible SQL queries. And I (and the host languages) tend to be verbose.
0

Share this post


Link to post
Share on other sites
Telastyn, Is SQL a good productivity language? Does it cause more coding lines to be written each work time by nature? I am wondering if certain languages by themselves tend to increase the lines per day compared to others. I am just curious if you or anyone else here has worked with SQL to make a game or simulation and if it could increase productivity if used for part of a game.
0

Share this post


Link to post
Share on other sites

SQL is a domain-specific language used for database queries, not a general-purpose language, AFAIK.

Just as HTML (for example) is a domain-specific language for web-page markup.

0

Share this post


Link to post
Share on other sites

Are there languages which make everyone who uses them write more lines per day compared to other languages?  Are scripting languages this way?

0

Share this post


Link to post
Share on other sites

Yes, scripting languages and other interpreted languages allow you to code faster, because there are no compile times.

Python is like that. This is why scripting languages are often used even in games written with compiled languages.

 

But lines of code is not the goal of scripting languages - the goal is to speed up the "code -> compile -> test -> repeat" by removing the "compile" part which causes a periodic jarring delay while in the middle of working. Scripting languages often allow you to then compile the script afterward to either bytecode or assembly, for faster execution (Resulting in a "code -> test -> repeat until satisfied -> compile" process).

 

But before worrying about faster development, it's far more important to learn how to develop quality code. If you focus too much on coding quickly instead of coding skillfully, you fall into a number of very bad programming practices, like making your projects unmaintable and hard to expand later, and fixing problems by monkeying with it 'until it works' instead of understanding the cause of the problem. sad.png

 

In a world increasingly immersed in software, the last thing we need is more programmers who just want to slap some code together without understanding the consequences, or who just care about 'getting the job done' leaving the mess for the next person who comes along, instead of doing the job right the first time.

Also, as software projects continue to increase in scale, slapping code together rapidly will be increasingly recognized as undesirable, and the market will shift (and has already started to, from what little I understand) to favor quality programmers. Good programmers can always "turn off" their skills and quickly write code to get something done (as much as they shudder at the thought). Bad programmers can't "turn on" skill when it's required, and you'd be setting yourself up for defeat in the marketplace, in my possibly-flawed prognostications*.

 

 

*Sweet! I finally managed to work that word into a sentence. *checks it off the list*. Next up: Onomatopoeia

Edited by Servant of the Lord
2

Share this post


Link to post
Share on other sites
But lines of code is not the goal of scripting languages - the goal is to speed up the "code -> compile -> test -> repeat" by removing the "compile" part which causes a periodic jarring delay while in the middle of working. Scripting languages often allow you to then compile the script afterward to either bytecode or assembly, for faster execution (Resulting in a "code -> test -> repeat until satisfied -> compile" process).



But before worrying about faster development, it's far more important to learn how to develop quality code.

 

 

How good is C# for the post-compile process?  What about Python and Lua?

 

 

causes a periodic jarring delay while in the middle of working.

 

 

Is the delay in workflow, execution, or both?

0

Share this post


Link to post
Share on other sites

But lines of code is not the goal of scripting languages - the goal is to speed up the "code -> compile -> test -> repeat" by removing the "compile" part which causes a periodic jarring delay while in the middle of working. Scripting languages often allow you to then compile the script afterward to either bytecode or assembly, for faster execution (Resulting in a "code -> test -> repeat until satisfied -> compile" process).

How good is C# for the post-compile process?  What about Python and Lua?


I'm not sure about C#'s scripting capabilities - C# is normally a compiled language, but it has some kind of ability to use itself as a scripting language - someone else will have to answer with more details. Python can compile to assembly IIRC, and Lua can compile to a very fast byte-code.

causes a periodic jarring delay while in the middle of working.

Is the delay in workflow, execution, or both?



Workflow, not execution. Mind focused, you're working hard, now you need to compile so you hit 'compile' and twiddle your thumbs for two minutes or more while you can't do much work. Personally, it breaks up the mental 'groove' I get into. Edited by Servant of the Lord
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0