Is it logical to estimate cost of project depends on source lines of code?

Like those calculated reports from tools such as

How to convince [somebody|employer|client] to pay depends on those reports ? The weird things come to scene when I see something like $83,862 based on my project.

Sometimes the developer [him|her]self would write more lines of code because of this estimating.

So if the count of the source lines isn't worthy, Why should be [sometimes|somehow] interesting part of development, Specially for employer, It does amaze them but why doesn't have any effect on pricing ?

Hey Employer I've developed this project that worth $1 million dollars, This source code counter program will prove it.

Maybe I don't know the real worth of my work, Should I public it for people and collect some comments about it or show it to some [experts|consultants] to find-out or just estimate myself upon my knowledge, And all of these solutions aren't right or at least logical.

And what happens to those codes I didn't wrote by myself, I mean sometimes we just copy a piece of code and [pasted|modified] into project.

And if estimating in this way is wrong, What is the purpose of these tools to generate such a report about source lines of code, Average hourly work and other facts.

Ohloh :

Estimated Cost

We calculate the estimated cost of the project using the Basic COCOMO model. For those familiar with the details, we are using coeffcients a=2.4 and b=105.

Estimate still seems way off?

Software cost estimation is tricky business even when all the variables are known (which we certainly don't have). One thing to remember is that COCOMO was created to model large institutional projects, which often don't compare well with distributed open-source projects. Beyond just development time, COCOMO is meant to include the design, specification drafting, reviewing and management overhead that goes along with producing quality software.

This model seems to be most accurate with mature, large projects. Young projects with little activity are typically overvalued.

I know quote from ohloh isn't just about SLOC

closed as unclear what you're asking by Ixrec, durron597, GlenH7, user22815, user40980 Jul 19 '15 at 2:51

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Future is hard to predict, but joelonsoftware.com/items/2007/10/26.html – Job May 6 '12 at 17:30
  • 6
    Its about time not lines of code – Murph May 6 '12 at 19:16
  • 2
    "I developed" Past tense, so no bean counter software necessary. Just "this is how many days you paid me to work on the task, this is how much you pay me per day, multiply the two to get the total development cost". If they want to, they can add office costs, utilities, equipment value depreciation etc etc. – a CVn May 7 '12 at 12:14
  • 1
    What would you do if I were to remove all the indentation and formatting, significantly reducing a number of lines? – CodeART May 7 '12 at 21:20
  • Recommended reading: How do I explain ${something} to ${someone}? – user22815 Jul 18 '15 at 15:02

You should not estimate based on lines of source code. You should estimate based on the time needed to implement the necessary changes, and that comes from your own experience and extensive knowledge of your codebase.

As you mentioned, estimating based on lines of source code could mean developers purposely write more code when it isn't necessary. Why would you ruin your codebase like this?

  • 3
    Estimation based on time may mean that you take more coffee breaks to pad the time it takes. So Time/Lines of code are just as flawed. – Martin York May 6 '12 at 19:03
  • @Loki Astari: Well then you are being completely dishonest. If I end up overestimating the amount of time that was actually needed, I just do some refactoring or more testing. – Bernard May 6 '12 at 19:51
  • 4
    That is my point. Just as you can inflate lines of code you can inflate time. Both estimates are flawed in exactly the same way. There is no difference in these two ways of estimating cost. – Martin York May 6 '12 at 20:02
  • 3
    From a maintainability standpoint, wasting LOC is a lot worse than wasting time. – Brian May 7 '12 at 15:34
  • 1
    The monetary value of code is based on two opposing factors. The value of the functionality to the client. The cost of creating the code to the publisher. Cost is not just a factor time but also on the experience (and thus hourly wage) of the developer(s) building the code. The actual value of the code is at a point where the ROI is positive for the client and the the publisher also makes a profit (but the publisher may be able to amortize the cost over multiple clients). This will be totally unique to the situation so applying arbitrarily meaningless measurements (time or LOC) is meaningless. – Martin York May 7 '12 at 20:07

Estimating based off LOC's is purposefully bad and I thought the industry as a whole had moved on from it.

However you as a developer should know how to price for your own worth, if you have to justify to a client why it's cost for a specific feature then that's what you'll have to do.

Clients/bosses are overly interested in what they're getting at a low level (in general), they care about the result. For them either the result is worth and they're happy to pay it because it achieves , or it achieves but they think it was more money than was worth.

And rounding back, telling a client how many lines of code there is in a product might make them go "oh cool!" and not change the price as it's totally abstract. Ford will tell you there's 160bhp in your Fiesta and make you go "oh cool!" but you won't throw them another £5k.


Piece of code 1:

return this.Data.Products.Where(c => c.IsEnabled).GroupBy(c => c.Category).Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

Piece of code 2:

return this.Data.Products
    .Where(c => c.IsEnabled)
    .GroupBy(c => c.Category)
    .Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

Piece of code 3:

Func<Product, double> pricePredicate = c => c.Price;
Func<Product, bool> predicate = c => c.IsEnabled;
Func<Product, string> keySelector = c => c.Category;
Func<IGrouping<string, Product>, PricesPerCategory> finalSelector = c =>
    new PricesPerCategory(
        category: c.Key,
        minimum: c.Min(pricePredicate),
        maximum: c.Max(pricePredicate));

return this.Data.Products

Those three pieces of code do the same thing and compile very probably to the same IL code. As you may notice, the third piece of code is unreadable because excessive variables and lines of code were added just to grow the LOC while decreasing the code quality.

Why would somebody pay more for bad code in the third example, and pay less for the better code in the second one?

  • Who says they would pay more? If your company allowed code like example 3 to be delivered then their conversion factor of SLOC to Hours would be different than a company that tends to write efficient code. So the example 3 company might claim 9 SLOC per hour while the first company might claim only 3 SLOC per hour. If everything is the same (which we know won't be) then the number of hours worked will still be the same, so you would expect that each company charged the same price, even if example 3 company wrote 3 times as much SLOC because a company generally charges based on how long it take – Dunk May 7 '12 at 20:34

Whenever these types of questions come up, I always think about this article I read in paper form when it was published. Fortunately, it has made its way to the net: http://www.dvorak.org/blog/whatever-happened-to-wordstar-2/

In particular, this quote is interesting:

In four months Barnaby wrote 137,000 lines of bullet-proof assembly language code. Rubenstein later checked with some friends from IBM who calculated Barnaby’s output as 42-man years.

According to the article, he wrote 137k lines of (implied) fairly defect-free code in four months. Some other individuals estimated this output as 42-man years.

Estimations can combine many facets, including LOC, that can be used to "estimate" the cost in developing a system.

So the question is: Would you rather pay Barnaby for the four months that he worked on the project or the 42-man years that it was estimated to be equivalent to?

I know this isn't an exact correlation, but it's something to think about.

  • 4
    Just confirms the old adage "A good programmer is a hundred times more productive than an average programmer" – James Anderson May 7 '12 at 7:47

SLOC can be an effective means of pricing projects when historical company metrics are kept. Also, it is not simply a matter of the project is x-number of lines of code and price according to that single metric. You have to break the system into modules and functionality. Then for each module you have to take into account, how much is new, how much is reused, how much is redesigned, how much is auto-generated, the difficulty level, the expected developer's familiarity with the module, the developer experience/productivity level, the destination platform and company historical results for similar functionality. In the end, this gives an ESLOC (Effort SLOC) number that can then be used to price the software. It is a tried and true method of quoting software used by many companies quite successfully. The key is that historical records must be kept since a company's culture and the type of applications that are developed affect the schedule to a great degree.

While pricing software using SLOC works for many companies, it should also be noted that it is completely ineffective at evaluating software developer productivity. Better software developers will write far, far fewer lines of code than mediocre or bad programmers but get many times the functionality than the mediocre developers in those fewer lines of code. In fact, the good developers tend to get negative productivity (when using SLOC as the metric) when they go in and refactor away hundreds or thousands of the mediocre developers lines of code because it should have been written so much more cleanly and easier to understand.

  • +1 @Dunk well said. I'd thought we'd gotten past any measurements based on lines of code. Clearly, I am wrong. – Chuck Conway Dec 24 '12 at 17:09

No, it's not a good idea to try and equate lines of code with an amount of work. LOC can be used as an extremely rough estimate for the size of a program, but that's a negative trait. You don't want a program that's more complex then it needs to be. Even the simplest tetris clone could have millions of lines of code if made horribly.

As an alternative, I suggest you find a consultant that has the skill-set for this project. Send him a description of the job and ask for an estimate. (Which, since you have no intention of actually hiring him, isn't the nicest thing to do. So buy him lunch or something afterwards.)

Consultants charge an arm and a leg because they can, theoretically, walk in with the exact skill set and knowledge base you need and can get the job done quickly. Show this price quote and he should be at least a little happier.

The free market is a fantastic means of finding the real value of a thing.

  • 1
    Can anybody say Ethics 101 :) – Dunk May 7 '12 at 15:51
  • Yeah... But if you're up front about why you want a quote, it'll affect the quote. Handing a tainted quote to the boss would likewise be unethical. – Philip May 7 '12 at 22:00
  • Reminds me of the saying: if you want a job done quickly, give it to the laziest guy in the office they'll find the easiest way to get it done. I can think of nothing more lazy than getting someone else to do your job for you. If you were on my team you would become my official estimator. – Dunk May 8 '12 at 14:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.