Mechanics of "Lines of Code"

Suppose you develop a project with a certain LOC of your own but you use custom libraries, obviously libraries are themselves already compiled (no such thing as "lines"/not source code) so in theory your program could be a mere 10 LOC but the enourmous linking in of libraries would make the program very advanced. Is that true? Also I hear some companies pay per LOC. Like a dollar a line? Hell yeah lets make plenty use of whitespace, hehe ;-)

Will a developer always include his own LOC or can you take snippets from some previous databases whose code isnt really compiled as library package but rather uncompiled source code...?
In my experience lines of code has virtually no real correspondence with the advanced nature of a program.
That makes me feel better because I at times feel demoralized with codes in the hundreds of thousands of lines. Do you feel that at times these source codes are "diluted" somewhat?
A few years ago I was working on a Higher Education ERP system written in VB ringing in at about 4,000,000 LOC. In order to replace the aging system we developed sort of an API in C# to plug and play modules with new technology in the ERP system. The C# app mirrored the exact functionality of vb and included some new functionality, but was only 1,000,000 LOC. The lesson here is that an impressive number of LOC may lead to inefficiency and can be a sign of an unmanageable code base. This is of course not always the case. It also doesn't mean you should try and write as little code as physically possible. I've seen some programmers write the most convoluted, obfuscated crap you can come up with just to save on LOC. Then you end up supporting it down there road and don't know what the hell it does.

Sputnik wrote:
Also I hear some companies pay per LOC. Like a dollar a line?


As a consultant I've never heard of this model before. Maybe it applies to some Russian programming sweat shops.
In project management, the planning of large IT projects is often based on LOC estimations. However, this is not actually related to the LOC of the final product, nor will the LOC ever be used as a measure.

Generally, IT projects are mapped out in terms of Functional Points (look up FPA or Functional Point Analysis; there are different methods but the core reasoning remains the same), which are translated into LOC based on certain rules. One of these rules is "code reusability" (estimation of amount of code that can be reused from elsewhere, with or without some adaptations), which should answer your second question.

Of course, the latter only counts for internal projects. External developers will probably never say where they got their code (which is their right, imho).
Gaminic wrote:
in project management, the planning of large IT projects is often based on LOC estimations.


Not sure where you are getting this from, but project management never takes into account LOC. It's not even something that is considered during the planning phase of a project. Why would a PM or BA care? I've never heard of a project that has a restriction on the LOC count, but rather on reinventing the wheel, hence SOA.

Also, in regards to estimate techniques, FPAs are are not the typical estimation technique unfortunately. You'll often find it is based on expert judgment or review of similar projects or some half ass standard a company has developed.
During my internships, the company I was placed at used LOC measure for budget estimation purposes, using the COCOMOII model. Also, I was wrong when using the term FPA (got it confused with something else); the word I was looking for was FSM. We used the COSMIC-FFP model.

They told me this was an industry standard, though I have no idea if that is true.
Gaminic wrote:
They told me this was an industry standard


Unfortunately its rather difficult to pinpoint an industry standard. Every organization does it a little different. While there are some more popular techniques, industry standard would imply that everyone is doing it. Most organizations do not have a mature model in place for estimation and other development activities... even the big ones. I'm currently consulting with a CMMI level 3 company and they are a disaster internally. It also has to do with the development methodology the project runs on.

Edit: Are you working in Europe? I've found that the methods employed outside of the US are completely different.
Last edited on
Topic archived. No new replies allowed.