4 ms·

When I came out of college, some real life examples of people who do not seem to care at all which shocked me: - CTO of a company I worked for (brother in law

by kayman 10y ago

When I came out of college, some real life examples of people who do not seem to care at all which shocked me: - CTO of a company I worked for (brother in law of the company director) typed with 2 fingers. No Joke - Senior Software developer to nullify a list, he just creates a "new list" instead of setting it to "null" End result from practical point of view is the same. But the lack of computer science insight baffled me. - Team lead implements lines of code as a tool to measure productivity. Being a new kid out of school, I felt too young to call bullshit but intuitively, I felt the metric was flawed.

niij 10y ago
Peck and typer here. I didn't learn to type "correctly" but I can still do my job.
mikekchar 10y ago
One thing to keep in mind is that there is a difference between a metric and measure. A measure is basically exactly what it says on the box: it's something that you have measured. A metric is a measure that you use to drive process changes. LOC is a good measure, but a truly terrible metric. The reason it is a terrible metric is because it easily gamed (both consciously and unconsciously). The same functionality can be implemented in 1 line or 100 lines. The amount of time it takes to write 1 line can be more than the amount of time it takes to write 100 lines. You get the point. LOC can, however, be a good measure. You can test this yourself if you like. Go through an old project (something with a year's worth of code). Make a list of all the features that were implemented in that year. Estimate the amount of work for each feature (or use whatever estimates you had before). Make a rolling average of "amount of work" over each week. Now go into your code repository and make a rolling average for the number of lines of code changed each week (so basically just add the lines added to the lines deleted). I think you will find that there is a correlation between the average estimated effort and the average change in LOC every week. This is because over the life of a project, developers tend to use the same kinds of techniques, the same idioms, etc. Occasionally, you will find that the relationship between estimated effort and LOC changes dramatically. In my experience, you will discover that this corresponds with a change in development mentality. Something has happened on the team that changes the way they write code. So it's a good measure for that kind of thing. For example, I once had to deal with political problems from upper management where they were convinced that the programmers were not focusing on their job. I could show them very easily from graphs of estimated effort and lines of code that it was very much business as usual. All this to say that if your team lead is encouraging you to increase your number of lines of code out the door, then it is indeed a flawed metric. But if the team lead is measuring productivity with lines of code, it may very well be a decent measure. You can't use it to affect productivity, but you can use it for other purposes.
hex13 10y ago
"Being a new kid out of school, I felt too young to call bullshit but intuitively, I felt the metric was flawed." You should have said that to the team. Especially that if anything goes wrong in project, usually it's new person on the board / junior programmer that gets the blame. Besides not telling that was just not honest to the team. I think we should all learn from each other, no regard with the job title.

by kayman 10y ago

niij 10y ago

Peck and typer here. I didn't learn to type "correctly" but I can still do my job.

mikekchar 10y ago

One thing to keep in mind is that there is a difference between a metric and measure. A measure is basically exactly what it says on the box: it's something that you have measured. A metric is a measure that you use to drive process changes. LOC is a good measure, but a truly terrible metric. The reason it is a terrible metric is because it easily gamed (both consciously and unconsciously). The same functionality can be implemented in 1 line or 100 lines. The amount of time it takes to write 1 line can be more than the amount of time it takes to write 100 lines. You get the point. LOC can, however, be a good measure. You can test this yourself if you like. Go through an old project (something with a year's worth of code). Make a list of all the features that were implemented in that year. Estimate the amount of work for each feature (or use whatever estimates you had before). Make a rolling average of "amount of work" over each week. Now go into your code repository and make a rolling average for the number of lines of code changed each week (so basically just add the lines added to the lines deleted). I think you will find that there is a correlation between the average estimated effort and the average change in LOC every week. This is because over the life of a project, developers tend to use the same kinds of techniques, the same idioms, etc. Occasionally, you will find that the relationship between estimated effort and LOC changes dramatically. In my experience, you will discover that this corresponds with a change in development mentality. Something has happened on the team that changes the way they write code. So it's a good measure for that kind of thing. For example, I once had to deal with political problems from upper management where they were convinced that the programmers were not focusing on their job. I could show them very easily from graphs of estimated effort and lines of code that it was very much business as usual. All this to say that if your team lead is encouraging you to increase your number of lines of code out the door, then it is indeed a flawed metric. But if the team lead is measuring productivity with lines of code, it may very well be a decent measure. You can't use it to affect productivity, but you can use it for other purposes.

hex13 10y ago

"Being a new kid out of school, I felt too young to call bullshit but intuitively, I felt the metric was flawed." You should have said that to the team. Especially that if anything goes wrong in project, usually it's new person on the board / junior programmer that gets the blame. Besides not telling that was just not honest to the team. I think we should all learn from each other, no regard with the job title.