Re:Keeping up with the Zenters
by adamsmith on Sunday March 02, 2008 @07:26PM
(#127678)
At Xobni I singlehandedly wrote 30,000 lines in three months.
That fucking hurt.
But that sunk cost was my #1 motivator during the first year. I remember telling myself that I had to make this work, because if I didn't then I'd have to start all over again.
There was a point a long time ago where Xobni was very close to dying. PG said to me "Well if xyz happens then Xobni will be dead."
I was hesitant to argue against PG in those days, but I remember saying without hesitation "No, if xyz happens then I'm moving to Texas to live with my parents and eat Ramen noodles for as long as it takes to come back. I will not let this thing die." I couldn't bear the thought of starting over.
Re:Keeping up with the Zenters
by pg on Sunday March 02, 2008 @07:15PM
(#127674)
Come to think of it, I believe the guys who wrote the most code this past summer were the Anywhere.FMs, who also got bought in the first 6 months. So while I would not want to encourage people to equate LOC with quality, it does seem to be a good sign when founders write a lot of code.
Re:Keeping up with the Zenters
by nostrademons on Monday March 03, 2008 @09:28AM
(#128067)
You can also exclude certain file patterns by throwing in a grep -v or two, eg. my command for counting JavaScript lines and excluding 3rd-party libraries is:
Re:Keeping up with the Zenters
by reitzensteinm on Monday March 03, 2008 @07:00AM
(#128007)
55,000 lines of code in the Rock Solid Arcade games so far (4 games, including one bigger unreleased in development). Started work around 3 1/2 months ago. I'd have written them in fewer lines, but I didn't have the time.
Re:Keeping up with the Zenters
by xirium on Sunday March 02, 2008 @10:09PM
(#127762)
It usually takes more than three weeks to prepare a good impromptu speech. -- Mark Twain
Writing, when done well, takes time. Some journalists write to a certain length and then shorten to improve quality. A similar process occurs when programming. A scaffolding is required and the final program is smaller. Unfortunately, this process of honing is greatly undervalued and often skipped. It takes significant time and creates less impressive statistics when you've finished. Regardless, the reduced volume of code will be create a long-term saving.
That fucking hurt.
But that sunk cost was my #1 motivator during the first year. I remember telling myself that I had to make this work, because if I didn't then I'd have to start all over again.
There was a point a long time ago where Xobni was very close to dying. PG said to me "Well if xyz happens then Xobni will be dead."
I was hesitant to argue against PG in those days, but I remember saying without hesitation "No, if xyz happens then I'm moving to Texas to live with my parents and eat Ramen noodles for as long as it takes to come back. I will not let this thing die." I couldn't bear the thought of starting over.
I guess {} globbing is bash specific?
We've gone from about 20k to 45k LOC in 2 months.
However, this includes white space and comments. So probably 1/2 or 2/3 of that.
http://www.dwheeler.com/sloccount/
http://cloc.sourceforge.net/
Here's a hypothetical example of what often happens to me:
1. Have a problem, need a module, copy a template: 100 LOC.
2. Add meat to the bones: 500 LOC.
3. Start testing & find gaps: 700 LOC.
4. Keep testing until it works (almost) perfectly: 1000 LOC.
5. Refactor, rename variables, tighten comments, pull common objects, strip out what was never really needed: 300 LOC.
A lot of work to get to 300 LOC, but I couldn't have done it without writing 1000 LOC in the first place. How do I measure that?
Writing, when done well, takes time. Some journalists write to a certain length and then shorten to improve quality. A similar process occurs when programming. A scaffolding is required and the final program is smaller. Unfortunately, this process of honing is greatly undervalued and often skipped. It takes significant time and creates less impressive statistics when you've finished. Regardless, the reduced volume of code will be create a long-term saving.