Ask YC: What is the SLOCCount output for your project? | Hacker News Reader

Ask YC: What is the SLOCCount output for your project?

dwheeler.com

6 pointssutro7 comments

I recently pointed this impressive tool at a project of mine and got the following. Care to share the sloccount output for your project?

  SLOC	Directory	SLOC-by-Language (Sorted)
  18246   sutro   java=18246

  Totals grouped by language (dominant language first):
  java:         18246 (100.00%)

  Total Physical Source Lines of Code (SLOC)                = 18,246
  Development Effort Estimate, Person-Years (Person-Months) = 4.22 (50.63)
  (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
  Schedule Estimate, Years (Months)                         = 0.93 (11.11)
  (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
  Estimated Average Number of Developers (Effort/Schedule)  = 4.56
  Total Estimated Cost to Develop                           = $ 569,991
  (average salary = $56,286/year, overhead = 2.40).

  Totals grouped by language (dominant language first):
  ansic:        29367 (70.03%)
  asm:           9186 (21.91%)
  sh:            3124 (7.45%)
  perl:           257 (0.61%)

I've always found those cost estimators to be rather useless (they are often off--literally--by orders of magnitude). A far better estimate would be to look at the actual development cost of competing commercial products with a full-time development team.

It also depends heavily on how the program is designed: it's possible for the same amount of "effort" worth of code to vary by a factor of ten or more between two programs that serve the same task. Some programmers naturally write extremely terse code that makes heavy use of abstraction, while others tend to be quite verbose.

Plus, it's one thing to write code: it's another thing to have that code become good. My project above has not changed significantly in code size in almost three years, despite the fact that every year has had more development than the previous one.

Such metrics would state that the value of the above project has merely doubled since it was originally conceived in a personal CVS repository by original developer Laurent Aimar, despite the fact that easily 95% of its value has been added since the original bare-bones framework released five years ago.

Not bad for a two-year old project in my spare time.

Totals grouped by language (dominant language first): java: 37239 (62.27%) cpp: 22390 (37.44%) sh: 159 (0.27%) perl: 10 (0.02%)

Total Physical Source Lines of Code (SLOC) = 59,798 Development Effort Estimate, Person-Years (Person-Months) = 14.67 (176.09) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC1.05)) Schedule Estimate, Years (Months) = 1.49 (17.84) (Basic COCOMO model, Months = 2.5 * (person-months0.38)) Estimated Average Number of Developers (Effort/Schedule) = 9.87 Total Estimated Cost to Develop = $ 1,982,269 (average salary = $56,286/year, overhead = 2.40).

(Gah, I can't figure out how to get the output to appear verbatim in the comment)

I generally use Construx Surveyor for counting...

This is going to sound harsh, but if you still this SLOC counts for anything, you're in PHB territory.

Not necessarily. If you are a competent developer (ie. dont use copy-paste too often) SLOC is a pretty good metric for how complex you code is. Especially the change over time in SLOC in the same project.

Now if you believe that high and increasing SLOC is always a good thing (rather than perhaps a warning signal), then your hair is getting pointy.

Wrong.... It's a foundational method for proxy based estimation. PHB usage is giving out bonuses based on SLOC counts.

Reply on news.ycombinator.com