Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

gnasher729

Suspended
Nov 25, 2005
17,980
5,565
You could measure this against actual project size (say in 100's of man years). Big companies have, and used to report source LOC instead of binary as a (very approx.) scale of productivity.

There is a quote from Steve Ballmer of all people making fun of IBM for doing exactly that on this thread. And "Any not completely incompetent programmer can double their productivity according to any performance metrics, without any increase in productivity. ", not by Ballmer, but still true.

There are plenty of horror stories of good developers with a brain dead manager, who write excellent code that falls short of the performance metric of the day, and then give up and start writing ****** code that exceeds everyone else's in performance metrics.
 

notjustjay

macrumors 603
Sep 19, 2003
6,056
167
Canada, eh?
Given that "As a Real World Programmer." is not a complete sentence, it is hard to assess. What I suspect the professor might have been trying to say is that there are only three distinct lines of code that make up the bulk of a program, that you will write them many thousands of times with slight variations.

A bit of an exaggeration, but not too far off from reality.

It is true that we seem to solve the same problems over and over again, just in different applications and in different languages.
 

firewood

macrumors G3
Jul 29, 2003
8,107
1,343
Silicon Valley
And "Any not completely incompetent programmer can double their productivity according to any performance metrics, without any increase in productivity. ".

That's why it's not a performance metric. It's a measure of relative project size for large projects after the fact. If a programing team padded their work by 2x on 2 projects, they might still end up with about the same order of LOC on each.
 

softwareguy256

macrumors regular
Jun 5, 2010
131
0
Sorry dudes as a professional and entrepreneur in the business making large amounts of cash, LOC matters.

I mean you could write a crappy 10k line toy app and sell 5000 copies a year for 1.99 before the 30% take and taxes, big freaking deal you made less than 10k a year.

If you want to scale and make the big bucks you're gonna need features. And thats going to take many lines of code. We're talking 500k to millions. Go ahead, cheat 10x by writing in the most verbose fashion, most of you will get tired and quit waaay before the 100k mark. It takes top talent to produce even 100k of code in 1 year that is coherent and stable enough to be built on for year 2, 3, 4, and on.
 

softwareguy256

macrumors regular
Jun 5, 2010
131
0
Think about what you said, you're greatest achievement is getting paid to add no new features that will increase sales and help cover your salary. Money must grow on trees or this is a fast path to a pink slip.

One of my greatest achievements working in software was culling thousands, maybe 10s of thousands of lines of unused code from a system. The president of the company told me this was not worthwhile, because there "are no bugs in code that doesn't run". The truth is that there are bugs, but you don't know if they'll ever be run or not, so you don't know if you should fix them. Our build was faster, our greps were faster, and it was easier to follow what was going on.

Other instances of reducing LoC involve removing duplication, reducing complexity, increasing modularity, etc. is a joy. One way to look at LoC is how expensive it is to maintain and enhance a system.

-Lee
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
Think about what you said, you're greatest achievement is getting paid to add no new features that will increase sales and help cover your salary. Money must grow on trees or this is a fast path to a pink slip.

Improving build performance, increasing dev productivity.
Reducing time to find and fix bugs.
Reducing surface area to verify when implementing features.
Clarifying and documenting true dependencies/structure.
Gaining insights into system structure, increasing effectiveness.
Cleaning up a big mess, making it easier for developers to understand system structure, decreasing training time for new devs.

If you're deciding who gets pink slips, and you hand them out to those that take initiative to solidify a system's foundation, improve tools and procedures, and gain deep system knowledge and expertise, I weep for the state of a large system under your tutelage after a few years.

Adding features is great. Making a system easier to add features to easily and safely is better. You may disagree, more power to you.

-Lee
 

Sander

macrumors 6502a
Apr 24, 2008
519
66
My guess is that softwareguy256 works in a small company. Maybe even running his own one-man show. That's great; the paying customers obviously couldn't care less about the build efficiency or the amount of dead code; they pay for features.

If I started a new company, I'd probably hire a few guys like softwareguy256, who clearly are feature-oriented. Features sell.

However, if my company grows beyond, say, 10 people, and we're making software which still pays our rent 10 years from now, then I would be desperately looking for a lee1210: Someone who is not too proud to clean up other people's mess and makes sure we can still add "selling features" next year, and the years after that.

Features are an asset, code is a liability.
 

notjustjay

macrumors 603
Sep 19, 2003
6,056
167
Canada, eh?
Sorry dudes as a professional and entrepreneur in the business making large amounts of cash, LOC matters.

I mean you could write a crappy 10k line toy app and sell 5000 copies a year for 1.99 before the 30% take and taxes, big freaking deal you made less than 10k a year.

If you want to scale and make the big bucks you're gonna need features. And thats going to take many lines of code. We're talking 500k to millions. Go ahead, cheat 10x by writing in the most verbose fashion, most of you will get tired and quit waaay before the 100k mark. It takes top talent to produce even 100k of code in 1 year that is coherent and stable enough to be built on for year 2, 3, 4, and on.

What? :confused:

You're talking about two different things here: the price which you choose to sell an app for to be profitable, and the features you include in your app.

If you want to write code professionally then absolutely you want to write good code with good features to sell your product. (Edit: originally I wrote "lots of features" but I realized this is not necessarily true; sometimes you just want the code to do one thing and do it in a really bombproof way).

LOC should not be the metric by which you determine whether you have been successful. It can however help you estimate the cost of the labour involved (tools such as SEER are designed for this) since obviously higher LOC means higher cost to develop and maintain the code. This can influence the price you sell the app at, but not necessarily.
 
Last edited:

ArtOfWarfare

macrumors G3
Nov 26, 2007
9,545
6,042
Metric for measuring performance:

Features / (LOC * Development Time)

Although it's hard to define a feature and it's hard to define development time... IE, I want to include time spent relearning what the written code does months later in this time...
 

firewood

macrumors G3
Jul 29, 2003
8,107
1,343
Silicon Valley
Metric for measuring performance:

Features / (LOC * Development Time)
...

Unless you end up with quick&dirty code that is too terse to be maintainable. See the obfuscated code contest for extreme examples.

All these measures are only for "on average" and "assuming everything else is roughly equal".
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.