Give ne back my hat!

SLOCs

It's funny how there is a consensus among the experienced developers here (and everywhere really) that counting lines of codes is an idiotic metric of productivity at best, and pernicious at worst, yet, people still talk about it as if it were meaningful.

There doesn't seem to be any way to generate a meaningful and accurate number that measures software productivity in a generic way. Why is that so hard to accept?
Permalink Shylock 
November 13th, 2017 2:38pm
I don’t find it idiotic

It’s a good rough measure of complexity


I use it to manage my own time
Permalink Wonder Woman 
November 13th, 2017 2:42pm
What's funny is that you're clearly confusing people who use it as a measure of software complexity with people who use it as a measure of programmer productivity.
Permalink . 
November 13th, 2017 2:43pm
It's a terrible measure of complexity, and some projects pack much more complexity in a dozen lines of code that a monkey coder web app with 20,000 lines of copy paste CRUD code imposes. I mean, if the domain is of a static complexity you might be able to compare A and B, but generally it is a totally dogshit metric.
Permalink Simulacrum 
November 13th, 2017 2:53pm
It's idiotic for both. Tell me, how are you going to calculate the SLOCs for this:

http://1.bp.blogspot.com/-PKkOQlbF4ic/T3rkMgDNYMI/AAAAAAAAAWU/l6FQCaL45iA/s1600/scd_type2_effective_date_mapping_complete.jpg

Do I really need to enumerate why SLOCs are idiotic again?
Permalink Shylock 
November 13th, 2017 2:55pm
LOC is extremely useful to me for project planning and accurate estimation.

I've given up debating or discussing it with anyone though because 100% of those arguing don't know shit about estimation and are absolute morons and nothing can be said to educate them, so fuck it.
Permalink Reality Check 
November 13th, 2017 2:57pm
+1 RC

The only other argument I hear regularly is "measuring productivity is impossible" so "be agile.. plan nothing."

It's generally from not very productive employees.

>
http://1.bp.blogspot.com/-PKkOQlbF4ic/T3rkMgDNYMI/AAAAAAAAAWU/l6FQCaL45iA/s1600

Feels like about 300 lines of SQL schema. A couple days work.
Permalink @oddball 
November 13th, 2017 3:00pm
lol. right.
Permalink Simulacrum 
November 13th, 2017 3:03pm
Yes, right. I'm completely serious.

You guys that piss on metrics NEVER can estimate beyond stupid stuff like "take a random guess and multiple by 20".
Permalink Reality Check 
November 13th, 2017 3:14pm
I take my gut feeling and double it. For new guys, I triple their estimates.

Works pretty well.
Permalink Shylock 
November 13th, 2017 3:15pm
But in reality, the best way to estimate is backwards. Give the client a date, and try to figure out what you can deliver by that date.

Makes for much happier clients.
Permalink Shylock 
November 13th, 2017 3:16pm
I did read a paper some time ago that showed the number of bugs in a program is highly correlated with the number of lines of code.
Permalink libtard_uk 
November 13th, 2017 3:31pm
>>LOC is extremely useful to me for project planning and accurate estimation.

How can you know the line count before you have written the code?
Permalink libtard_uk 
November 13th, 2017 3:32pm
SLOC is a concrete, measurable metric that can be generated by a tool from your existing code-base.

It's harder to maintain (and comprehend) a 10,000 SLOC set of code than a 1,500 SLOC program.

So SLOC has a purpose.  Sadly, that purpose is not widely recognized nor embraced.  Instead we try to use it as an estimate of size (which sucks), an estimate of effort (sucks), an estimate of code quality (really sucks -- smaller yet complete is better), or God forbid, an estimate of Programmer quality.

Still, trying to estimate these things is a worthwhile endeavor.  Sadly, again, some SWAG estimate is either poured in concrete in some Proposal/Design document, or, more commonly, a carefully worked out estimate is cut in half by Sales or a Manager.

So the quest for a useful estimation metric continues.  Because SLOC isn't it.
Permalink SaveTheHubble 
November 13th, 2017 3:36pm
The real problem is if programmers know management is measuring lines of code then you can be sure they will be writing a lot more code than is necessary. So it's worse than ineffective, it actually has a negative affect on projects.
Permalink libtard_uk 
November 13th, 2017 3:38pm
... when used for the wrong thing.  Yes.

And sadly there's no definitive guide that says what the wrong things are, and the right things are.

Kind of an "anti-pattern for SLOC use" might be nice.  But hell, we can't even get a definitive consensus for what indents should be...
Permalink SaveTheHubble 
November 13th, 2017 3:41pm
I've never been measured in lines of code but always on "projects", a.k.a. tasks. So management doesn't give a fuck weather you finish a task in one line or 10,000 as long as it gets done.

Usually though, a task that takes 10,000 lines would be allocated more time than a single line one, probability for this going up when it's greenfield development.

Not generally true for maintenance and very improbably for bugfixing. I've spent a week chasing a bug where the fix consisted of a single line of code and was congratulated rather than scolded for wasting time on not coding.
Permalink Io 
November 13th, 2017 3:54pm
Inserting one line of code:  $10.

Finding out WHERE to insert the line of code, and WHICH line of code to insert, without breaking other stuff:  Priceless.
Permalink SaveTheHubble 
November 13th, 2017 3:59pm
Two guys in my group generate close to zero LOC per any period.

Measuring them is easy and useful.  Damn it.
Permalink Legion 
November 13th, 2017 4:43pm
Do they have good productivity though in the fields of creating drama and politics?
Permalink Reality Check 
November 13th, 2017 5:00pm
Maybe send them to your meetings so you can code
Permalink Q 
November 13th, 2017 5:28pm
>SLOC is a concrete, measurable metric that can be generated by a tool from your existing code-base.

Is it? Today I wrote a 12 line query which generated 15000 insert statements which generated a fuckton of C code which generated a fuckton² of assembler.

Which number do you want?
Permalink Shylock 
November 13th, 2017 5:30pm
>It's idiotic for both. Tell me, how are you going to calculate the SLOCs for this:
>
>http://1.bp.blogspot.com/-PKkOQlbF4ic/T3rkMgDNYMI/AAAAAAAAAWU/l6FQCaL45iA/s1600/scd_type2_effective_date_mapping_complete.jpg

Was that a rhetorical question? Are you really just that dumb? You generate the DML - which will be about ~200-250 lines of code.


>Do I really need to enumerate why SLOCs are idiotic again?

They're not.
Permalink . 
November 13th, 2017 5:40pm
>Is it? Today I wrote a 12 line query which generated 15000 insert statements which generated a fuckton of C code which generated a fuckton² of assembler.

>Which number do you want?

12. The number is 12.

For fuck's sake...
Permalink . 
November 13th, 2017 5:41pm
> take my gut feeling and double it. For new guys, I triple their estimates.


Yeah that’s much better than SLOC... gut feeling
Permalink Q 
November 13th, 2017 5:50pm
For personal tracking, lines of code is a metric that is easily obtained and vaguely useful.

Another is tracking the actual time spent coding vs. other tasks like meetings.
Permalink Z 
November 13th, 2017 5:56pm
>Was that a rhetorical question? Are you really just that dumb? You generate the DML - which will be about ~200-250 lines of code.

Actually dot, that diagram generates XML:

https://github.com/autodidacticon/informatica-powercenter-automation/blob/master/src/app/config/dtd/powrmart.dtd
Permalink Shylock 
November 13th, 2017 6:02pm
>Yeah that’s much better than SLOC... gut feeling

It works pretty well actually.
Permalink Shylock 
November 13th, 2017 6:03pm
>12. The number is 12.

>For fuck's sake...

Actually, 12 is really just the number of returns in the text. I like a neatly formatted query. It was just one query, so you could say I wrote 1 line of code today.

And got the job done.
Permalink Shylock 
November 13th, 2017 6:05pm
do you have the XML that corresponds to the picture?
Permalink @oddball 
November 13th, 2017 6:09pm
A lot of idiots here seem to thing that working hard is a good thing.
Permalink Shylock 
November 13th, 2017 6:09pm
>do you have the XML that corresponds to the picture?

No I don't. BTW, that was an example of a horrible mapping. At their worst, the data flow diagram programming tools create programs that look like wiring diagrams.
Permalink Shylock 
November 13th, 2017 6:11pm
>I like a neatly formatted query.

In my experience, this has a high correlation to the quality of the code.
Permalink Z 
November 13th, 2017 6:29pm
> A lot of idiots here seem to thing that working hard is a good thing

Who said that?
Permalink @oddball 
November 13th, 2017 6:43pm
>Who said that?

I inferred that from dot's sneer that I _only_ wrote 12 lines of code today.
Permalink Shylock 
November 13th, 2017 6:46pm
>In my experience, this has a high correlation to the quality of the code.

It really does! The act of hand formatting it brings out issues that you wouldn't otherwise have found.
Permalink Shylock 
November 13th, 2017 6:47pm
It was only 12 lines. For fucks sake you want to count each assembly instruction for each bit that gets flipped deep inside the microprocessor? Get real
Permalink @oddball 
November 13th, 2017 7:08pm
Shylock's, you are being stubborn just because.

I wrote one line of code today that called a .Net method. I'm sure the library function I called had over 1000 lines of C# code. It probably generated tens of thousands of lines of IML. It was executed by a runtime that had hundreds of thousands of lines of code, and ran on an operating system with a couple of million lines of code.

So how many lines of code did I write? One, 1000, 100000, or 2000000?
Permalink Legion 
November 13th, 2017 7:13pm
Shylock's got a chip on his shoulder since he writes queries, not "real code"
Permalink X 
November 13th, 2017 7:45pm
No. My point was that it really doesn't matter how many lines of code it takes to get the job done. Just get the fucking job done. You're not working in an assembly line.

My other point about the 12 vs. 15K vs. a fuckton is that any idiot can game the count to what the idiot manager wants it to be, if they're stupid enough to measure productivity by the number of lines you type a day.
Permalink Shylock 
November 13th, 2017 8:11pm
This whole thread though proves my point. People just need to have a metric that produces a number, even though the number is bullshit.

In more important matters, people still hold by "hundred year flood" "five hundred year flood" and other nonsense, even though the past few years have shown that it just doesn't work. People need the security of a number, no matter how flimsy.
Permalink Shylock 
November 13th, 2017 8:33pm
People using lines are bullshitters, but double your gut or triple what he says works. Your opinions are simplistic and self-serving. It's hard to believe you are employed as a "programmer" at all.
Permalink X 
November 13th, 2017 8:38pm
Ah, but I am, and have been since 1983.

But it's interesting you disparage gut calls as to how long something will take, or how much you can accomplish by a certain date. Since there is no real rigorous way of estimating the effort, you are only using your gut whether you realize it or not.
Permalink Shylock 
November 13th, 2017 8:46pm
Those are your inane thoughts not a refutation of mine. In particular, I emphatically disagree with your view that there are no ways better than gut. There are some better and some worse.
Permalink X 
November 13th, 2017 8:55pm
Which way is better?
Permalink Shylock 
November 13th, 2017 8:56pm
Lots of people claim that random guessing estimation times a factor just plain works.

When you then try to rely on their estimates, you run into complete failure as the estimates have no correlation to the actual date.

Every single time without exception these people have a bunch of excuses.

"Ah but no one could have foreseen that Sue would quit two weeks before delivery, thus the six month delay was inevitable. If not for that my estimate was correct."

"Ah but no one could have foreseen Bob would be run over by a bus and my two best testers elope and leave for a job at Google, causing a 17 month delay. If not for that my estimate was correct."

"Ah but no one could have foreseen that the servers would crash and none of the backups would work, causing the project to be cancelled. If not for that my estimate was correct."
Permalink Reality Check 
November 13th, 2017 8:59pm
That's why I take my gut and double it.

Project managers don't like my estimates, but I'm right far more than I'm wrong.

I also take into account the fact that the requirements never stay the same as you go through data discovery.

If I get the chance, I ask for 3 months to go through the data with an experienced PM to come up with a much more realistic estimate. But almost no one will pay for a realistic estimate, so I use my gut.
Permalink Shylock 
November 13th, 2017 9:02pm
SLOCs are good if no one tries to cheat.

Of course, if 12 lines of code one day saves 8 days of writing 1000 lines of code, i certainly will an Indian for 8 days...
Permalink Rk 
November 13th, 2017 9:35pm
>> Which way is better?

Here's one.

> go through the data with an experienced PM
Permalink X 
November 14th, 2017 7:40am
Sure. If the client will pay for it, sure.

Big if.
Permalink Shylock's Phone 
November 14th, 2017 11:07am
Okay, so now we've moved from "oh jesus there's nothing better than my gut" to "look at the data."

So, we agree.

If your deadline is important, look at the data hard and make a good estimate. If your deadline is a bunch of meaningless nonsense for internal masturbation, by all means double or triple your gut.
Permalink X 
November 14th, 2017 4:20pm
To be fair, most deadlines are a bunch of meaningless nonsense for internal masturbation.
Permalink Qaz 
November 14th, 2017 4:32pm
Yes, when you paid to spend 3 months to examine the data and judge competency and reliability of the people you are going to be working for (i.e., how likely is it that they are going to change their minds), then your gut feelings will generate a much better estimate.

Unless you have an algorithm for judging the competency and reliability of the people you work for (please let everyone know if you do) then it's still your gut.
Permalink Shylock 
November 14th, 2017 6:02pm
What ? Now you think the gut gives better estimates than looking at the data?
Permalink Weeeerrrrve 
November 14th, 2017 7:14pm
If you are given a static requirement that you are guaranteed isn't going to change, then yes, you could just look at the data and give a pretty reliable estimate. But that is never the case. There is no way to judge people without relying on your gut. So no.
Permalink Shylock 
November 14th, 2017 7:23pm
So not “If I get the chance, I ask for 3 months to go through the data?”
Permalink Weeeerrrrve 
November 14th, 2017 8:09pm
Our gut feelings are still based on something.

We also know more code in general leads to more error. No one competent just writes more code just because.
Permalink Rk 
November 14th, 2017 8:12pm
Yes Rk.

If you can write 12 lines of code to solve a problem, or a thousand, which is probably the better solution?
Permalink Shylock 
November 14th, 2017 9:06pm
Depends on what kind of companies one works for.
Permalink Rk 
November 14th, 2017 9:52pm
Shylock has trouble holding a coherent opinion.
Permalink X 
November 15th, 2017 5:27am
Because developing data applications for people is very rarely a coherent affair.
Permalink Shylock 
November 15th, 2017 5:52am
X, have you ever taken a data app from POC to delivery to production?
Permalink Shylock 
November 15th, 2017 5:55am
In this thread you said gut is most accurate then look at data then back to gut. Right?
Permalink X 
November 15th, 2017 5:59am
I was first speaking in generalities, then got more specific.

You didn't answer my question. Care to?
Permalink Shylock 
November 15th, 2017 7:26am
Sure, I've put dozens of data applications to production. Full stack. From POC to profit. It doesn't have anything to do with your inability to hold a thread.

You completely reverse your opinion.

1. My gut is best
2. Looking at data is best. (But I can't afford it)
3. My guy is best


Which stages were you more specific?

You should just admit you do projects where the estimates aren't important so you do bullshit estimates.
Permalink X 
November 15th, 2017 7:32am
You didn't answer my question. Care to?
Permalink X 
November 15th, 2017 9:02am
"you do projects where the estimates aren't important so you do bullshit estimates"

That's a very concise and accurate summary of that methodology. Thanks for that.
Permalink Reality Check 
November 15th, 2017 10:58am
The reason IT project estimates are often exceeded is people realise there are often zero consequences when it happens.
Permalink Qaz 
November 15th, 2017 11:05am
Joel has pointed out that if you take the most likely target date, there's a finite amount of space to the left of that date going back to the start of the project, where there's a 0% chance of delivery that day, BUT there is "infinite space" to the right of the most likely target since the project could take forever, especially if like the F-35 the goals are physically impossible and yet no one will cancel it for fear of losing face.

As a result of this, you are far more likely to go way over than under at all, even if the date is literally the most likely delivery date.
Permalink Reality Check 
November 15th, 2017 11:29am
>Sure, I've put dozens of data applications to production.

OK, so what's the secret sauce that I'm missing? Are your estimates right on the mark all the time? How big are these projects? Is there a particular algorithm that you've developed that spits out a precise number?

If you're not bullshitting here, you should write a book, develop training materials and get a consulting firm started, because if you have figured that out, that's a road to wealth beyond the dreams of avarice.

As for me, it goes like this: there's always a gut feeling involved. The more time you have to investigate things, the closer your gut feelings will match reality. But I have yet to see an algorithm account for the randomness that free will brings to the table.

In other words, in the immortal words of FDR, a foolish consistency is the hobgobblin of small minds...
Permalink Shylock 
November 15th, 2017 7:46pm
BTW, what kind of data applications did you do? Master Data, data warehousing, some sort of big data?
Permalink Shylock 
November 15th, 2017 8:05pm
> The more time you have to investigate things, the closer your gut feelings will match reality.

Now you’re back to agreeing with me. Looking at the data is better than gut.

> immortal words of FDR,

Emerson.

FDR is “So, first of all, let me assert my firm belief that the only thing we have to fear is...fear itself — nameless, unreasoning, unjustified terror which paralyzes needed efforts to convert retreat into advance.”
Permalink X 
November 16th, 2017 5:59am
This was the same speech in which he was closing the banks for a bit.  Which people had been hugely afraid of.

Thus this speech.
Permalink SaveTheHubble 
November 16th, 2017 11:57am
What’s it like to know nothing, but share your opinions with reckless abandon anyway?

It was his first inaugural. No mention of closing banks.
Permalink X 
November 17th, 2017 5:17pm