

A Thousand Lines of Code Per Week - palish

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 <a href="http://www.folklore.org/StoryView.py?project=Macintosh&#38;story=Switcher.txt&#38;sortOrder=Sort%20by%20Rating&#38;detail=medium" rel="nofollow">http://www.folklore.org/StoryView.py?project=Macintosh&#38;s...</a> :<p><i>"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."</i><p>How fast do you write code?
======
cperciva
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.

~~~
zemaj
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.

~~~
dpapathanasiou
_no one uses LOC any more_

I feel obligated to mention the classic LOC management story:
[http://folklore.org/StoryView.py?project=Macintosh&story...](http://folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt)

~~~
create_account
What would -2000 get you if you used it in YC's application form?

~~~
palish
$100,000 in funding.

------
pg
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!

~~~
create_account
_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)

~~~
pg
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.

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

~~~
dpapathanasiou
_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.

~~~
smg
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

~~~
staunch
> 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.

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

~~~
juwo
great point

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

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

------
edw519
Perhaps "Refactor %" would be a better measure than LOC. Turn 1000 lines of
code into 100 lines of better code. Then we can talk.

~~~
juwo
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._

------
euccastro
I never counted them.

