Recently a friend of mine bought an inventory application from a vendor, who used an statement like "built based on 10000 lines of codes" as a marketing slogan to increase its market share. I've also seen other software claiming to being built with a special language (C#, PHP, Java, etc.), or based on a special technology.

My question is that, can we morally and logically price a software based on these factors? I mean, does it matter to the end user how many lines of code have we written? Or which programming language did we use?

A factor like platform seems to be logical in this case, because some users want an application to be executed on Windows, or Mac for example. But what about other factors like technologies used, architecture, lines of codes, programming language, even database?

closed as primarily opinion-based by user40980, durron597, user22815, TZHX, gnat May 30 '15 at 7:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    10,000 LOC may just be a sign for a lousy programmer who doesn't know what he is doing, if somebody else can build it with 5,000 LOC in the same language it's most likely the better code base. – thorsten müller Jul 20 '11 at 18:31
  • 7
    I am going to market my next software as, "Coded in an office with a Keurig coffee machine". If lines of code is a metric for software quality then so is the availability of decent coffee to developers. – maple_shaft Jul 20 '11 at 18:51
  • @maple_shaft: I'm not convinced to buy your product yet... what kinds of coffee capsule thingies do you have for your Keurig? – FrustratedWithFormsDesigner Jul 20 '11 at 19:21
  • 3
    @maple: From what I've seen the coffee machine is probably a better metric. – configurator Jul 20 '11 at 19:24
  • @FWFD, Kona is my favorite, something about the coffee growing in fertile Hawaiain volcanic ash gives it that satisfying taste. ;) – maple_shaft Jul 20 '11 at 19:52

The language matters if the vendor gives the customer the source code to make changes. Otherwise, it might matter for performance (a desktop application written in C means it probably starts up faster than something based on a virtual runtime like JRE or .NET).

The lines of code is there to give the customer who is thinking of rolling their own application an idea of how much effort is actually required to build it. Honestly 10k LOC is a relatively small piece of software, so I find it odd that they'd use that as a marketing statement, but still, that's why you'd do it.


To answer your question more directly, "can we price is based on LOC?"

Yes, you can. Morally, logically, whatever. You can price it any way you want. Whether the customer will buy it, that's entirely up to how convincing your sales pitch is.

  • 3
    +1: "Honestly 10k LOC is a relatively small piece of software" - all too true. I was just working in a single source file yesterday that was 13k LOC, and it's just a small component of a very successful commercial product. – Bob Murphy Jul 20 '11 at 18:26
  • 1
    The number doesn't matter here @Scott. What matters is that should, or could software companies use such slogans? Aren't these factors misleading and non-relevant? – Saeed Neamati Jul 20 '11 at 18:28
  • 1
    @Bob Murphy, a 13k line file...do you smell that? – CaffGeek Jul 20 '11 at 19:03
  • 6
    LOC, by the way, is a terrible measure of anything. I worked for a company whose management was really happy with the LOC output of a team of Chinese programmers. That was because they employed copy-and-paste programming, so yes, their LOC output was great, and so was their ability to duplicate the same bug twenty places in the code stream. At one point, they copy-and-pasted the entire sources of jpeglib into their code. Then they did it again. In fact, they did it six times. But boy, was management happy with their LOC numbers! – Bob Murphy Jul 20 '11 at 19:27
  • 1
    @Bob Murphy - I do agree it is terrible, but I've been reading a book by Greg Wilson called Making Software. It's about real evidence of what works and what doesn't work in software development. He mentioned in a talk I saw that lines of code is the only metric that's correlated to bug count. Also, see this quote on the SO blog: "...the single most correlated measure of productivity is simply lines of code written. Joel counters with that only holds true, so long as the developers don’t know they are being measured based on that...". – Scott Whitlock Jul 20 '11 at 20:14

It's to help convince customers who think they can just do it themselves in a few pages of VB code that it's more difficult than they think, and to buy whatever is being sold instead.


My question is that, can we morally and logically price a software based on these factors?

What does morality have to do with it? As far as logic is concerned, a lot depends on whether you have a niche product or mass market product.

You are not going to become rich by developing a niche product. The main goal is to make a profit, any profit, period. How much it cost you to develop the product is certainly a part of the equation for a niche product, and code size is a key factor in the development cost. Look at COCOMO, for example. Code size is a big factor of the estimated development cost in COCOMO, and it remains a big factor in more modern descendants of COCOMO. Another factor for the price charged for niche products is how much it would cost someone to reverse engineer your product, but that too is highly correlated with code size.

The economics changes drastically if the product is a mass market product. Code size is less of a factor if you have lots and lots and lots of customers. A game developer can amortize absolutely astronomical development costs over hundreds of thousands or even millions of purchasers.


It's marketing-speak. Hopefully your friend knows that LOC (Lines Of Code) has no relation to the quality of the final product. The closes analogy I can think of right now would be to sell cars with marketing info boasting about the number of screws and fasteners in the car. Would the number of screws used to hold a car together be the deciding factor (or even weigh in at all) when buying a car?

Marketing based on language might matter if the customer will be doing integration programming or running on a particular platform.

If the customer wants to buy a progam that has more LOC than another program that's fine, though it doesn't really make much sense.

The question of "is it moral/ethical?"... Boasting about LOC is a pointless metric and it preys on customers that don't know better and think "more LOC => Better program", so I'd say NO.

  • I've seen it matter a good bit which database backend it worked with. I don't want to buy Oracle if I can use my current SQL Server license. – HLGEM Jul 20 '11 at 21:54
  • 1
    "The new iThingy, now with a billion transistors!" – badp Sep 29 '13 at 0:48

It depends on the type of software.

For an Integrated Development Environment (IDE) or other software tool, the language is paramount.

For a third party library, the number of lines of code may come into play if deployment footprint is a concern. The language is also important as it may restrict interoperability.

For packaged or on-demand application software, it would seem odd for the language or the number of lines of code to be part of the function that determines the cost of the product. From the customer's perspective, the value the software provides to them is weighed against the cost of them performing the task manually (or with a cheaper solution). The customer is not going to care how many lines of code there are or what language is used, if it gets the job done for them.

If developers are the consumers (direct or indirect) of a piece of software, then the implementation (language, OS, lines of code, etc) may all appear in the price equation. Assuming there are no performance concerns with the implementation choices, other types of customers won't care.

In the case of your friend's inventory application, it sounds silly to me to market it like that.

  • +1 because of proper mentioning of software type in marketing strategy :) – Saeed Neamati Jul 20 '11 at 18:57
  • 1
    LOC does not always have a direct impact on the size of the installed executable binary (which would actually would be a good selling point if the target market is devices with limited storage, such as embedded software). – FrustratedWithFormsDesigner Jul 20 '11 at 19:33
  • @FrustratedWithFormsDesigner True. – Matthew Rodatus Jul 20 '11 at 19:35

Knowing the language is useful for the customer who wants to extend the application. I would prefer a system that used C# and an MSSQL database over one that used Java and Oracle, simply because there are more .Net developers than Java developers in my region, and they come at lower premium. Aside from applications that allow custom development, the language claim is not unethical, it is just poor marketing, since no one who is not going to extend cares what language it is written in. Remember, most users do not know the difference between VB and binary, and they really do not care to.

As far as LoC goes, Most companies probably use this as a pitch that their product is "super powerful", but I would be much more impressed by an ERP system written in 500 LoC than one written in 500,000, because the 500 line version is exponentially easier to maintain and extend. Once again, its not really unethical, mostly because its something that will not be anywhere on the radar for users, and may actually dissuade developers from buying.

In short, no, do not base your pricing scheme off of something that is 90% arbitrary and the customer associates no value with. It is not so much an ethical thing, but more of a basic business thing. It would be like if you were charged for your airline tickets based on how heavy the plane is and the brand of peanuts you get on the flight.


I just spent 5mins refactoring a 30 lines of code, into 10 lines of code doing the same thing. If the right framework was used, these lines of code could be reduced to one line or a config for data binding and validation.

Did I just reduce the value of the code to a third of it's original?


Certianly, Technologies used, architecture, and database are valid considerations when chooaing a solution for your business. Number of lines of code seems to be an mostly irrelavant though perhaps interesting slogan. Though in C# that could be misleading as I can put all of the instruction on one line per method and do a lot and make it look like i have less lines or space it out and make it look more. This says nothing about the quality or effectiveness of the product.

Pricing is a matter of market. If you can sell a product that took you 20 minutes to make for 8 billion dollars to a company that is going to make more off of it then good on you i say. Pricing per line of code is not likely to be a successful business model, I would think.


I'd say, as much as the company is willing to disclose, I am willing to learn. Like any product - customers will make their own decision based on their needs, knowledge and perceptions. Here's some factors (mentioned and unmentioned) that seem meaningless but may not be:

  • LOC - yeah, on the surface, I care very little. This can fluctuate really hugely based on architecture, coder talent and any number of other things. It is a good point of reference for someone who can actually write code who is doing an eval. If something is WAY off what you'd think reasonable, it's probably worth asking the sales rep why.

  • Programming language - having worked with both Java and C APIs, I have learned that (generally!!) a Java API that claims a ton of different OSes may actually accomodate them all. A C API that makes the same claim had better show me some evidence of test practices. I actually used a C API that was "compatible with" Sun Solaris and HP UNIX, where "compatible with" = "compiled successfully on". Seriously not the product I was looking for!

  • Underlying technologies - not common, but I'll take it if they tell me. I love knowing whatever I can about the architecture, because it gives me some insights on where the product is going and what it's weak points may be.

  • COTS - ie, other software (like a database brand) needed to run this application - a MUST HAVE for anything big (like a database or directory server) - I once saw a proferred solution that offere 3 different types of database for 1 system. Although all of it was "part of the application" - I couldn't help but think such a thing would be an IT nightmare. In an Oracle shop, for example, it gives everyone a warm fuzzy to know that the sexy new app can run with an Oracle database underneath, cause it reassures your sys admins that their current network configuration, back up procedures, and other configurations are likely to work OK. And for the security nerds - we want version and patch level so we know what security vulnerabilities have been fixed!

  • Who wrote it? (not asked) - if you work in the defense industry, this is an obvious one, military apps often have to be written (and supported!) domestically. I tend to think this one is the biggest tradeoff of all - after all, just because something wasn't written in the US does not mean that the product is low quality. IMO, this can seem a little racist... but if you care, you care. After all, why not? "Made in the USA" labels help sell T-shirts, right?

Speaking as a systems engineer who's looking at a whole lifetime of a solution - I want to know as much about the internals as the vendor will tell me. In fact, I'd much rather have this stuff than all the "it will enable your business, drive your task force and satisfy your customers" marketing fluff that I see on the front page of pretty much every website!

If I want to think about ethics, I think the most ethical thing is to figure out what you're willing to disclose and then find the most honest way of disclosing it. For example, don't tell me you have 10,000 LOC, and then let me figure out that that is only a tiny part of the overall product (like the "core" that does nothing but is needed by everything). If you tell me that a part is 10,000 LOC, then also disclose the LOC for any libraries I'll need. It's the false advertising that gets me down.

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