Timeline for Are there known valid uses of SLOC to measure productivity?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2017 at 14:11 | comment | added | Berin Loritsch | @ConorMancone, Using SLoC rates within a project might be OK because you are comparing apples and apples. It's the thought that you can make blanket assertions that language X is more efficient than language Y because of the number of lines of code written--regardless of whether they are active lines of code or simply declarative statements. My argument is that using SLoC for that comparison is simply broken. | |
| Nov 20, 2017 at 22:08 | comment | added | David K | I don't disagree with the last few comments; in fact I very much agree with the comment that "we're just trading hypotheses." But even under the hypothesis of "more code per day, less code per task," we still find that N times as much code doesn't mean N times as much productivity. (It may mean a lot more than N times as much productivity.) And the OP's question is actually about languages, where the "more code per day" part seems less likely to apply (at least, not in a good way). | |
| Nov 20, 2017 at 21:54 | comment | added | Conor Mancone | @DavidK the comment from Quuxplusone clarified my meaning: the senior works at a high rate, the junior at a slower. The senior both writes code at a higher rate, and also needs less code per task. | |
| Nov 20, 2017 at 21:53 | comment | added | Quuxplusone | @DavidK: Agreed. Based on the gist of Conor's answer, I understood his scenario's numbers to be more like the ones I suggested (because he said things like "As a result, the more senior developer will get through their coding tasks quicker"). But I don't think this answer or either of our own comments are giving numbers supported by any actual science; we're just trading hypotheses. The answer to OP's question "Are there known valid uses... is there evidence...?" would appear to be "no", so far. :) | |
| Nov 20, 2017 at 21:51 | comment | added | David K | @corsiKa For the senior/junior comparison I think we're talking about similar tasks in similar languages. But I think we could build an analogous argument about the same developer working in different languages. | |
| Nov 20, 2017 at 21:45 | comment | added | David K | @Quuxplusone I was thinking 2KLoC in two days, but if it's 2KLoC in one day then we end up with twice as much code (10KLoC/5KLoC) in five days, but five times as much value (5 tasks/1 task), in which case SLoC/month is correlated to productivity but not proportional to it. OTOH if it's 2KLoC in 2.5 days you end up with less code but twice as much value, and the correlation is negative. | |
| Nov 20, 2017 at 21:38 | comment | added | corsiKa | To clarify, though, you're comparing similar tasks in similar languages? You're not comparing two similar things happening in different languages with LOC as a metric? | |
| Nov 20, 2017 at 21:14 | comment | added | Quuxplusone | @DavidK: I believe the suggestion is that the junior developer can complete one task in 5K LOC and five days; the senior developer completes the same one task in 2K LOC and one day, which leaves him 4 days to write another 8K LOC solving 4 more tasks. So the senior writes fewer LOC per task but a greater number of LOC per unit time; that is, a senior developer can "code faster," which matches my intuition too. (But it assumes that the devs are coding 24/7. If the senior spends 2 days coding and 3 days on Twitch, he still completes 2x the tasks of the junior but produces only 80% the LOC.) | |
| Nov 20, 2017 at 20:48 | comment | added | David K | "As a result, the more senior developer will get through their coding tasks quicker, and move on to writing different code at the same high rate." This suggests a scenario in which the senior developer writes 10K SLoC in the same time period as the junior writes 10K SLoC ("writing ... code at the same high rate"), but the senior completes more coding tasks in the same time and adds more value to the code. So by SLoC metrics we got identical productivity out of both developers, but the true productivity was not equal, was it? | |
| Nov 20, 2017 at 20:31 | comment | added | JimmyJames | One thing to consider here too is that there is an informal metric that is often used that I will call the 'hero metric'. That is, the people who are very visibly solving lots of problems are seen as being highly effective. The thing that people miss is that often the reality is that this person is creating brittle solutions that require lots of remediation. The people who build things that don't break and don't need any attention are not running around frantically saving the day. Their code just runs day-in and day-out without issue but to the casual observer, they seem to not be doing much. | |
| Nov 20, 2017 at 20:19 | comment | added | JimmyJames | As a developer I can think of many times I took a bunch of non-DRY code and replaced it with a small set of reusable functionality. I then added a significant amount of new functionality. Reducing the amount of code while adding a multiple of real value is a good thing in my book. In my experience, the best engineers write the least lines of code and the worst write the most. | |
| Nov 20, 2017 at 19:52 | comment | added | TessellatingHeckler | The question is asking if LoC can be used to compare tools and languages, in the context of the senior developer saying it shows higher productivity in "static" languages. You seem to be answering a different question - LoC can be used to compare developers, but you still agree it cannot be used to compare languages because a given developer writes the same number of LoC regardless of tool/language? You say you are contrarian against the other answers here, but it seems you are in agreement? | |
| Nov 20, 2017 at 17:37 | comment | added | Conor Mancone | We use gitprime (gitprime.com) in our company, and as both a manager and engineer, I think it's about the best thing in the world. Again, it's only part of the picture for us, but it has been extremely helpful in identifying potential problems with engineers long before there was an actual problem. The transparency is awesome, and everything they do ultimately boils down to SLoC. Given the amount of value and insight it adds, I'm always very dubious about the tendency of some engineers to dismiss SLoC out-of-hand. Anyone is welcome to their opinion but it definitely works | |
| Nov 20, 2017 at 17:26 | comment | added | Conor Mancone | @NathanMerrill That's a good point to, although less relevant to the OP: debugging is debugging in all languages and (off the top of my head), I see no reason why it would be substantially easier or harder from one techstack to another. That being said, that is a reason why, overall, you can't judge productivity exclusively on code written, anymore than you can on any other metric. | |
| Nov 20, 2017 at 17:14 | comment | added | Nathan Merrill | There's also one other exception: bug hunting. Bug hunting for especially nasty bugs can take a long time, but usually result in a single line of code change. | |
| Nov 20, 2017 at 16:13 | history | answered | Conor Mancone | CC BY-SA 3.0 |