A Thousand Lines of Code Per Week

7 points by palish ↗ HN
How many lines of code do you write in a week? Let's forget for a moment the fact that line counts in different languages can differ in productivity, and that line counts aren't the perfect way to measure program complexity. Let's also say if you write a line of code then delete it, it still counts as a line. Do you write over a thousand lines of code per week in the language of your choice? If so, Bill Gates says you're an excellent programmer. From http://www.folklore.org/StoryView.py?project=Macintosh&s... :

"Well, let's figure it out," he said in a slightly condescending tone. "I don't think it could be more than 10,000 lines of code, and a really good programmer like you should be able to write at least a thousand lines of code per week, so I think it will take you less than 10 weeks to write it, if you're as good as I think you are."

How fast do you write code?

27 comments

[ 2.8 ms ] story [ 75.4 ms ] thread
This depends entirely on the sort of code I'm writing.

If it's throwaway code -- that is, stub functions for use while I'm writing and testing other code, and which I know I'll replace before production use -- I can easily end up writing a thousand lines of code a week, or even more.

If I'm writing good, solid code -- that is, code which I expect to write once and then use for the next 20 years without ever making more than cosmetic changes to it -- I'll generally write about a thousand lines of code per month.

If I'm writing best-of-breed software -- that is, code which comes with a proof of correctness and at least a very strong argument for being the optimal solution (e.g., code which computes a roots-of-unity table in linear time with O(1) maximum error, and will thus never be surpassed by more than a constant factor) -- I'll typically write 100-200 lines of code AND a 5-10 page paper in a month. Of course, this last sort of code falls into the "yes, I would trust this to operate a nuclear power plant" category, which is a rather higher level than most applications require.

Very true. I can spend weeks researching and analysing the most import 100 lines in most of my apps.

no one uses LOC any more - that article is from 1984! I'm pretty sure Gates would have a different answer if asked now.

While I'm a firm beleiver that LOC are not a good measure of anything anymore ... The YC as this question:

"If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?"

I guess it's important in some places still .... :-)

They'd be better off asking: you much have you done, how many more weeks until you can release a prototype, etc.
That story sure brings Gates down another few notches in my book, as a programmer at least. Predicting how long it will take to implement a totally new program with lots of unknowns is crazy in itself. Trying to estimate how many LOC it will take _another_ programmer and then estimating a schedule on the fly like that is just pure fantasy. It's also unbelievably aggravating to be on the receiving end.

John Carmack's permanent answer on projects is "When it's done". The only truthful answer when developing anything new and interesting.

That story sure brings Gates down another few notches in my book

It seems he was a bully, too, at least in the early days: http://blog.tomevslin.com/2007/05/microsoft_memor.html

Then again, most people probably don't care, given Microsoft's financial results.

Hmmm I cannot really claim to read Bill Gs mind. But the man was an accomplished programmer and knew that great software gets built when a hacker commits himself to doing nothing else but working on it for a couple of weeks. I think he was just trying to edge Hertzfield into working on the Switcher. Another interesting take away from the story is how Gates focuses on what is good for the users and not on M$ controlling the Switcher
> I think he was just trying to edge Hertzfield into working on the Switcher.

He was trying to get him to do it really quickly so he could justify paying him as little as possible. He got it for $0, so that made him happy.

> Gates focuses on what is good for the users and not on M$ controlling the Switcher

He wanted to take advantage of the fact that his apps had very low memory footprints. Switcher was the way to do it. He had no need to control Switcher itself. The fact that he wanted the project done quickly to save money says to me he didn't really care about quality, which users obviously do.

This is an amusing lesson in how different people interpret the exact same thing so differently.

I once touched 2,700 lines in a day in a grand feat of manual code manipulation. That certainly made me want to code differently.
As I'm sure everyone will say, this heavily depends on what you are writing. If you are writing Windows Forms in C# using Visual Studio you could easily write 1,000 lines of code in an hour (because the IDE makes them for you). Similarly, if you are merely typing up what should be done by an ORM product, then you can easily write 1,000 lines of code in a day. I've had 3-4kloc days doing the combination of these two. It's possible because the coding is easy, and you have tools to help you do it.

Also, are we counting things like macros in this estimation? I mean, a single line macro could yield hundreds of lines of code once through the compiler.

Perhaps "Refactor %" would be a better measure than LOC. Turn 1000 lines of code into 100 lines of better code. Then we can talk.
I get very annoyed by LOC questions. They are idiotic. I was very, very surprised that PG uses it as a measure, in his interview to NYT and in the YC application.

In my day job, I am maintaining (and enhancing) a distributed system that was written by apparently Cobol programmers who switched to Java rather suddenly last year.

- apparently did not hear of functional programming, so 600-800 line sub routines with if-else-while nesting up to 7-8 levels deep. very hard to follow the logic.

- no knowledge of exceptions, so return codes were used.

- hand rolled socket server because application EJB servers were not on their radar.

- a pseudo "object-oriented" database layer with all sorts of design problems and takes 5-10 times the LOC (that I have written in a simple database access class to show them a better way).

Their output in terms of Lines Of Code is phenomenal but it is a maintainence nightmare.

That would still misrepresent the people capable of starting with 110 lines of code, then refactor it down to 100.
It may be the best answer is to change the question. Why do people measure LOC? Because they're trying to measure the productivity of programmers. Why are they doing that? Largely to decide how to reward them. So that is the ultimate problem. But it goes away if the programmers work in smaller groups, in the form of startups, because then the market decides how to reward them.

So odd as may seem, the answer to the question of how to measure LOC is: startups!

Why do people measure LOC? Because they're trying to measure the productivity of programmers. Why are they doing that? Largely to decide how to reward them.

Yes.

But if I'm an IT manager at a large company, the answer to that question is not startups (it's not LOC, either).

(I know this site is all rah rah startups and I'm not trying to harsh anyone's mellow, but this question is still largely unanswered)

To be fair, startups are one way to measure productivity. But since it takes 2-10 programmers for most startups to be successful, there's no way everyone can start a startup (at least right now).

So I was wondering more about what everyone's ability to pump out code is, in the simplest metric: programming language plus line count per day or week. And sorry, but I don't think auto code generation is fair to include unless you're coding the code generation (that is, you've set up a Lisp macro or something similar).

Here, I'll go first: In the last three days, I've built a 1200 line system which is of medium complexity. The language is C++.

Shawn

It could be, if you're a high enough manager. You could let two similar projects compete and see who got the most users internally, then release that.
I dont understand what your (pg's) question is.
Didn't you just publish an essay about deciding how much equity to give someone, and step one was putting a value on the recipient's potential contribution? Sure, the market evaluates a startup, but the market doesn't evaluate a programmer...except for single-founder startups.
It's not how many lines of code you write, it's how effectively you both turn out features and leave the code base in a clean state. The folks I've worked with who crank out lots of code tend to be the ones who missed reuse opportunities and did't refactor, leaving a mess for the people who came along later to extend their work.

Measuring by lines of code is silly unless you also have a way to measure code debt.

(comment deleted)
great point