Ask HN: How many LOC are you personally responsible for?
Question came up through complaining that I don't have enough shared responsibility with code I maintain. For how many LOC does the buck stop with you? I'm at 33,000 that I maintain daily and have zero support for (let alone documentation). It feels big but I've no idea how others compare.
2 comments
Again, fair, but I'm not trying to measure progress. I'm trying to gauge jurisdiction.
I don't think LOC is a good measure for that, too many variables that change the effort required for same-length pieces of code: How complex is the code? How much does it change?
And when comparing between people, what does "maintain" entail?
And when comparing between people, what does "maintain" entail?
That's a fair comment but I do feel it's a good enough proxy to gauge responsibility. There's also no other metric available that's any more concise.
I figured maintain to cover having originally written it and are charged with its ongoing use.
I figured maintain to cover having originally written it and are charged with its ongoing use.
I feel like you'd want to create an index that's something like (number of features) + (number of unit tests)^2 + (number of adjacent integration tests)^3
And maybe normalize for each by the lines of code for each component and some constant factor after twiddling.
Basically LoC by itself is meaningless. When you gauge responsibility you want to look at how many features are owned, how complex those features are (unit tests) and how critical those features are to the system/product (integration tests). With complexity/criticality being weighted much higher than feature count.
Of course like all metrics this is easy to game. But that's what code review is for.
And maybe normalize for each by the lines of code for each component and some constant factor after twiddling.
Basically LoC by itself is meaningless. When you gauge responsibility you want to look at how many features are owned, how complex those features are (unit tests) and how critical those features are to the system/product (integration tests). With complexity/criticality being weighted much higher than feature count.
Of course like all metrics this is easy to game. But that's what code review is for.