How Fast Can You Write Code
How Fast Can You Write CodePeak programmer productivity is much greater than average programmer productivity. How fast can you write code?
In college I once wrote 3000 lines of C++ in about 72 hours, and I probably wasn't working more than about 8 hours each day. Of course this was mostly the parser for a toy compiler and it involved a lot of CopyAndPasteProgramming.
At one point during my first job I rewrote from scratch some prototype parsing code I was working on. In this instance I wrote roughly 1200 lines of C code in about 4 days, again without working really long days. This code was fairly dense both in ratio of code to comments and white space and also in terms of raw functionality. I've long regarded this as the best benchmark of my peak programming performance.
While unemployed a couple of years ago I wrote a C++ library for reading and writing Free Hand 4.0 and 5.0 files, which I happened to know a lot about from my first job. Over a period of 5 or 6 weeks I created over 13000 lines of code, although I should mention that a substantial portion of the code came out of a code generator which I then fixed up by hand. It was also heavily commented (there is something twisted about generating comments from a code generator) and, being C++, it was pretty declaration heavy, too.
Now we all know LinesOfCode is at best a poor measure of programmer productivity, but it's not completely worthless. The level of productivity I achieved in these cases is clearly a lot higher than I normally achieve. I think it's important to point out that in the last two cases I had a very good idea of exactly how all the code should be written. You can write code very fast when you know what you're doing.
-- Curtis Bartley
Surely a meaningful measurement of coding speed should be qualified by a "minimum code quality" threshold. (It's not good enough just measuring the time taken to get to a clean compile if you have to pick up the tab later when it comes to debugging - that would be similar to SweepingItUnderTheRug.)
Certainly. But I don't know how to measure code quality, even as poorly as LinesOfCode (per unit time) measures measures productivity. All I can say is that I was pretty happy with the quality of code I wrote in the above examples.
This is an interesting subject, considering that many companies (IBM, I think) evaluate their programmers by LinesOfCode per day. Would it be more effective to judge by FunctionPoints, or time coding / time debugging? How many LinesOfCode does the average programmer put out a day? Where is the average? Is it increasing? Are people who can write many LinesOfCode (GrandMasterProgrammers) also good architects? And how do you increase the amount of code you can write?
-- WillSargent
This topic reminded me of somebody I was in college with who wrote a computerised quiz program as a flat sequence of "print(question); print(choices); read(answer); print(right_or_wrong);" statements. The program blew up to many thousands of lines in a very short space of time. In this case, the number of lines written by this novice programmer in a single unit of time was inversely proportional to her level of proficiency.
-- Anonymous
Like the old joke, "He has experience, he wrote over 350 kloc personally... Then he discovered loops."
I wrote about 1200 lines in a night for an OS design project last semester. By the due date, it compiled but didn't run. Well, it might've run if I'd taken out all the assertions (it kept failing on one of them), but it probably wouldn't have run correctly.
I just wrote about 600 lines of Scheme last weekend, on an interpreter for a Lispy language I'm developing. I think this is much more impressive functionality-wise. Currently, I've got literals, variables & binding, primitive procedures (anything in the underlying scheme), function calls, keyword arguments, positional arguments, LexicalClosures, and first class environments implemented. Not bad for a weekend's worth. And it seems to be working, or at least passing the unit tests.
-- JonathanTang
I type somewhere between 35 and 100 WPM, based on how many typos I'm willing to tolerate. Are we asking about how fast I put the characters in? But if not, and I assume we aren't, then I think we're really talking about some mix of ThinkingTime and TypingTime. ThinkingTime in turn has some mix of AnalysisTime and EmittingTime.
My problem with all these code-quantity metrics is that they obscure the reality of leveraged and reused code. It might take me all day to find just the right way of refactoring an abstract method hooked by zillions of descendents. The method itself might (at least in the Smalltalk environment) be only a two or three lines long. At yet, when I'm done, the consequences of my change might be extraordinary, altering almost all aspects of system behavior.
An early demo of the Smalltalk-80 environment was to make a few-keystroke change in the bowels of the text-handling code, which resulted in *every* text scrollbar in every window turning "electric", right *then* (no restart required, all the windows just *changed*). Not much code ... and during a demo, generally typed very slowly. The average developer, following an IBM-Style FunctionPoint metric, and paid based on LinesOfCode, would probably have edited every call site to accomplish the same end. QED.
-- TomStambaugh
I wonder... The right line of code in the right framework can save a lot of work, but I imagine that the savings in TypingTime versus ThinkingTime was probably balanced by a much longer AnalysisTime when it came to the framework. And the framework probably wasn't arrived at on the first time around ... lots of refactoring of repeated code went into creating a framework where that was possible.
Code quantity and quality are related in much the same way that architecture is. There has to be a good amount of foundation (at least ~50K? Is there a CriticalMass?) before building upon it.
I imagine most developers would work on the ThinkingTime before the TypingTime. Idioms work in the small as DesignPatterns do in the large to reduce the ThinkingTime.
Now if there were only some way to reduce the TypingTime...
-- WillSargent
Learn touch typing. ;->
The point I originally wanted to make and never got around to was this:
Peak programmer output is much greater than average programmer output. One conclusion that can be drawn from this is that the actual process of coding doesn't dominate development time. One implication of this conclusion is that writing more code won't necessarily slow you down much. This is one reason prototyping can pay off so much. You can spend a lot of time writing prototype code and then lose very little when you throw it away and start over from scratch. You can regain the functionality implemented in the prototype far more quickly than when you wrote the prototype because you are now programming (at least partially) in a problem space that you have just explored. This is exactly the kind of circumstance that one can achieve maximum productivity in.
So in one sense I am suggesting that writing a lot of mediocre code quickly is often a good idea, but I am also suggesting that you then fix it, refactor it, rewrite it, or start over from scratch as appropriate to get good code.
Am I making sense here?
Oooohh, you hit my sweet spot with that one. After reading TheGoal, a novel about (manufacturing) process management, I have been looking for ways to apply the main theme to software (The key idea is that rework or slowdown in a non-bottleneck station won't slow down the overall production time, but if that permits the bottleneck station to go faster, the overall process goes faster.) ! My version was written up as a software process pattern called GoldRush, in the RiskManagementCatalog, and I have been looking for other examples. Seems you found one. I hadn't connected peak versus average coding time with the rework and bottleneck station. Thanks.
I agree with everyone else that LinesOfCode is a terrible metric, but I've always wondered how it is ball-park measured? Number of lines in a source file minus the class comment? How do you all get the numbers 2,800 or 13,000? -- MichaelFeathers
C3's numbers are the number of newlines in the method source, plus 1. This is the number of lines in the method, including the method name, and including the comment if any. There aren't any, of course. ;-> -- RonJeffries
The 2800 figure was straight from memory, so I can't say very much about that. The 13000 figure was from a line count on all the .h and .cpp files including test driver code from my FreeHand reader project. I'm pretty liberal with blank lines and comments, so the line count will be inflated compared to the average C++ programmer's output. But even if that maps down to say 5000 lines of more typical programmer output, that would put me at an annual run-rate of about 50K lines of code, which I suspect is very high for C++ programmers. I wish I actually could sustain that rate for a whole year... -- CurtisBartley
Seen recently: "We need a really robust method that will allow us to write millions of lines of code..." Why do you need to write millions of lines of code? - maybe a better architecture/design would rid you of a lot of this code. After all, we want functionality not lots of code.
I'm suspicious of massive code generation because reuse is generally more effective. Code generation can be seen as automated CopyAndPasteProgramming.
Regarding "LinesOfCode per man month" productivity measures: I find my greatest pleasure, when maintaining programs written by others, in the elimination of code. Refactoring increases call-level reuse, reducing the amount of code needed to achieve the same function. Fortunately, no one has yet punished me for improving the quality and reducing the maintenance costs of their systems. (Not that I haven't been threatened and actively discouraged from it, but no one has overtly punished me for it - yet. ;-) -- JeffGrigg
Not that long ago, I wrote over 2000 lines in two eight hour work days. This was because I can touch type C++, and because raw COM code is very low level.
My preference - clearly communicated to developers - is for achieving a productivity level of NegativeLinesOfCode. While maintaining functionality, this always fixes bugs. -- EricUlevik
For my current project I've been averaging around 40 LinesOfCode an hour for about 103 clocked days spread over 9 months. (I'm working part-time.) This is C++, minimal comments and not much UI. That would put me in the 75 KLOC/year ball-park if I could sustain it full-time.
As it's part-time I think I can continue this rate indefinitely. These are pretty much ideal conditions for me. I'm working from home, without meetings or other distractions. The project is started from scratch so not much crap legacy code to deal with. It's a familiar problem domain, although different and complex enough to be interesting. -- DaveHarris
I tried reimplementing Wiki in PythonLanguage (PikiPiki) over the weekend, and it took about six hours to get most functions working in about four hundred lines with few comments but lots of vertical whitespace. That's not a particularly high number of LinesOfCode, but it's a lot of functionality, and it was a lot of fun to be in MentalStateCalledFlow for a while. I felt pretty productive, and would attribute it to understanding the requirements very well and to using a high-level language.
It could have been much larger if I hadn't practiced RefactorMercilessly.
As they say, it's not size that matters. LinesOfCode count for (almost) nothing. I read once that the average programmer produces 10 (ten!) lines of code per day. The real metric is FunctionPoint per unit time.
No it's not. The thing that matters is customer satisfaction per unit time. Less easy to measure than FunctionPoints I'll grant, but then they are a lot more difficult to measure than LinesOfCode.
I sometimes roughly measure my productivity in classes per day in OO environments or functions in structured/functional languages. And no, methods aren't good enough in OO world. The idea is that I usually represent each concept in the system by one class or one function respectively.
I usually write a class a day (and then delete another, and write another, and delete two..). Sometimes, I can generate 5-10 classes in one day, but then RefactorMercilessly over the next couple of weeks.
Let's reverse this and SubtractLinesOfCode. Once, two of us deleted 250 000 lines of code in three days, leaving us with around 30 000 lines. We eliminated the first 150 000 lines in five minutes. -- SunirShah
Writing several thousand lines per day is a sign of CopyAndPasteProgramming. Like you do, I prefer to apply tools like PeeEmDee to detect CopyAndPasteProgramming and then RefactorMercilessly.
For any project large enough, if you measure the amount of classes in the source repository, you will realize that writing a class per day per developer is reasonably as fast as you can go. Junior programmers usually can write a class or two per week. That's why I prefer to write small classes instead of BigFatClasses? (see FewShortMethodsPerClass), because small classes tend to have less bugs than big ones, so my productivity doesn't go down when I'm six months into the project because of ClassInvariants being broken. -- GuillermoSchwarz
I strongly recommend that y'all slow down. A year and some months ago I had a three-day programming blitz that was probably the most productive I have ever been. Unfortunately that was the final straw for my overworked arms and I have had tendinitis in them ever since. As a result, I can no longer type more than a couple of sentences at a time, have to use voice recognition software, and operate mice with my feet. You have been warned.
-- JamesWilson
Good point. I've found that a decent keyboard is crucial. A couple months ago, I spent a few days using a typical keyboard - I've used the Microsoft variety for years - and I found the typing position of the regular keyboard excruciating. Iterestingly, I also find even regular laptop keyboards somewhat more comfortable than regular desktop keyboards due to the short travel and light touch required. If I could just find a split keyboard with short travel and light touch I'd reach typing Nirvana.
See BewareOfTendinitis.
I once wrote a library in C of about 10,000 lines during 1 weekend (I didn't do much else that weekend, but I didn't just code either). This was actually not bad code, although it did need a bit of polishing later. The reason it came together so quickly was this: the library replaced one we had been using for ages, which was a real travesty. For the same functionality it came in at about 50,000 lines, had a terrible API, was buggy, and filled with strange idioms of the (no longer employed there) original progammer as well. So I had been thinking about the problems with this API for months before I said `screw it, i'm writing a replacement'. I had a very good idea of what was needed, and new the problem domain inside and out (on the other hand, there wasn't any copy and paste). As a result, this work was almost, but not quite, purely typing. My usual rate of output isn't that high.
The fastest code I ever wrote was done on a yellow (legal) pad. I was getting tired of using an external editor to handle messages: edit the message, leave the editor, run the message software, leave that, back to the editor, etc.; and wanted to build an editor into the message software.
The message handling program (which handled 5-bit telex traffic on an 8-bit micro) was written in 8080 assembly. The editor would, likewise, be written in assembly.
I woke up the next morning (a weekend), sat up in bed, picked up a yellow pad and a fountain pen, and wrote the entire editor, stopping only for snacks and "rest" breaks. The following Monday I typed in the body of code I'd written on Sunday, and it ran. It was more than 90% correct as written, requiring a few on-the-fly revisions while typing, and a couple of hours to fix the display-to-buffer link (I'd misinterpreted the hardware docs -- oops) and by the following day I was able to compose and edit message traffic in the same app that sent and received them.
I have no idea how many LinesOfCode were involved. I only know that I added a non-trivial feature that doubled the size of application, and had it working in one day of drafting plus one day of typing/debug and it worked as intended.
God, would I love to be able to do a major feature per day and have it just work! I've seldom gotten close to that since. It's got nothing to do with my typing speed. It has more to do with ProgrammingIsInTheMind.
OK, surprised I didn't see the following response:
How fast can you ask for it?
The fastest I can write code is by running a program that I wrote that generates code.
Also surprised that nobody brought up MonkeyMath. I'm sure there are ways to entice Monkeys to bang on the keyboard very quickly.
Also, at my company (SourceXtreme) we inherited a project that we used to jokingly refer to as a bunch of guys trying to break the GigaLocBarrier?.
Cheers, -- JasonNocks
We're not employed to write code. We're employed to SubtractLinesOfCode. All the code that was ever needed has already been written. Most of it was written in the 20th century, so it's mostly crap. But all the programmers' cribs^H^H^H^H^H manuals repeat it over and over again - oh, with slightly different languages and idioms - and the has-beens and never-will-bes dutifully CutAndRape? it into their latest projects. Which makes, after just a few weeks of development, a hopeless schmozzle. The real question is "How fast can you ReFactor code" ...
I've heard stories of large, high quality applications being written in a day or two by single individuals working continuously at clerical typing speeds. In each case the programmer had a clear goal, was sufficiently knowledgeable, and could avoid mistakes and especially stalls. The stories are reported by skilled colleagues who still find awe that complete applications could come together so quickly. These are the cases I remember;
After three years with my current employer, I've written almost 60,000 lines of Java. Though I spend less than half of my time coding, I've created 100 lines of tested, high quality code per day. And this is with an ongoing effort to refactor and reduce code size. Having a good refactoring IDE (Eclipse) helps a lot.
I was once asked to more-or-less "clone eBay within 3 weeks" in the late 90's when auctions suddenly were the "new, in thing". It had dutch auctions in addition to regular auctions, and user ratings. I programmed my ass off. I never counted the code volume of it, but it was a hell of a lot of programming. I don't have that stamina anymore. I learned a valuable lesson from one of the bugs discovered in it: If there was only one bidder, it calculated the rate wrong. I spent all my testing on more complex transactions and neglected a simple "one-zy" test. It's a fallacy that complex tests can be assumed to cover simple cases also. Complex tests are not necessarily a super-set of simpler tests. Other project testers made the same mistake: thinking the "tricky" transactions would more likely bust it. --top
Who cares how fast we can climb the wrong mountains? Surely a better measure of productivity is how fast a developer delivers VALUE?
-- JasonGorman
Yeah, but every now and then one has an 81-point night. It's fun to talk about.
I am a new comer and curious about so many people discussing the topic...
I just wrote 50 lines of code in 15 minutes. The purpose the code achieved was useful, but absolutely trivial.
A few days ago I refactored 163 lines of code into 185 lines of code in about four hours. Though the amount of code grew, I greatly deobfuscated the actual methods, making them easier to understand and more functional (mainly because I was using RefactorMercilessly).
In both of these cases I wrote a lot of code in a very short time, but the latter was a far more in-depth process than the former, requiring a deep understanding of the problems at hand, including compatibility issues and the learning of some new functions that I hadn't used before.
I think the correct way to measure a programmer's productivity is not in the quantity of code they use to achieve a task, but in how the task is achieved. Did they create a sloppy solution, implement inefficient methods, and/or write hard to understand code? Or did they create a clean solution with efficient methods that can be easily understood by their colleagues in the present/future?
The amount of code you write is completely irrelevant. What matters is how well you solve a problem or achieve an objective.
--M
EditText of this page
(last edited December 16, 2014)
or FindPage with title or text search