Ask HN: What if every aspect of your work was completely measurable? | Hacker News Reader

Ask HN: What if every aspect of your work was completely measurable?

8 pointsdlf12 comments

How would you feel if someone monitored various aspects of your work, such as

how many lines of code you write in a day,

business value of code you produce in a day (e.g. Pivotal Tracker points),

average “lifetime” of your code before it’s changed,

what percentage of your code is changed,

what percentage of code you write from scratch vs. changing others’ code,

when bugs are tracked,

what percentage of bugs are due to your code,

how many files you change,

what coding tasks you are good/bad at, AND

what languages you’re most/least proficient in.

What do you like about this? Would you use this to demonstrate that you are a strong coder and useful employee? Would it be helpful in keeping your work on track?

What don’t you like about it? Would you feel this was an unwarranted intrusion? If so, why? Would it make you angry enough to get another job or not work there?

View on HN

To me, the only one that I would value in a management role would be what percentage of bugs are due to your code the rest of them seem to be items that could be used politically, but have very little tangible value in measuring the value of a developer.

"how many lines of code you write in a day" being the least useful and possible the most harmful to the organization. For an example a developer that knows how to write lambda forms could write a generic routine and inject a reference to a function for one particular portion of customized logic, this would be very compact and efficient code, the same thing could be accomplished by an interface and classes, where each custom class implements a interface that contains the custom logic. The guy that understands lambda forms actually understands programming at a higher order as it is a more advanced concept, but the guy who only knows interfaces and OO will end up painting the better picture by that metric.

That being said, I would pay for the "what percentage of bugs are due to your code" tracking tool in itself, I think that is a valuable metric, if it is accurate.

At my first job, they brought in a well-known consultant company to update a huge legacy application. At one of the initial meetings, one of our co-workers who was working on the project gave us an overview of their process. Then he said something like:

"And they have a tool which will automatically go through the code, find bugs and then be able to tell us how many bugs each person is responsible for."

My initial thoughts were "Wow, that would be such a cool way to get feedback."

But then he added "I'm just joking about that one. You can wipe the worried looks off your faces."

I think a tool that could directly measure the amount of bugs one produces would revolutionize the industry.

If it's bugs and not just errors, then you've pretty much got a self-programming computer. Any such tool is necessarily only going to give you a rough approximation.

There are some tools that can help with this, such as Findbugs, for java. Obviously it can't find any bug but it matches against certain patterns to determine if some anti-patterns exist in a project.

How do you find bugs in perfectly good code, that does something efficiently and correctly but it's just the wrong thing?

Think about a piece of javascript that takes an image and replaces another with it. The problem is not the code, it's the incorrect image.

That kind of bug - for that's what it is - could never be determined without resorting to creating a set of instructions that would do the same thing. You would have to write something that behaved in the way you wanted you other code to behave in order to test against it.

This would be the perfectly idiotic suggestion of an accountant or auditor whose desire was to improve the bottom line without understanding the mechanisms.

There is another way around it, tracking who wrote the original code, and then tracking tickets marked as bug in which that code was modified could give a picture of who is producing bugs. It may not be a 100% accurate solution, but if a tool could seamlessly integrate ticket management with development code, that was changed to fix a bug, could be accurately tracked.

I think the main purpose of these is to catch the buggy code before it even gets checked in, not to assign blame to a developer

These tools generally don't work for dynamic languages, only for static languages, like Java. Also, as I said, its far from perfect, however even the Intellij IDE that I use has some features like this and makes some helpful suggestions. For example, if you needlessly reassign a variable (reassign it twice before it could be read by anything) it catches this, it catches some of the mistakes that developers tend to make when they've been hacking away for hours and are not paying close attention and thus helps to clean up the code.

If you have leverage, you'll get paid what you're worth. If you do not have leverage, you'll find that you've become a factory worker.

Current factory workers, call center reps, and cashiers, among others, have their performance constantly monitored and graded in a way very similar to what you describe.

Take a look at the checker's screen next time you're at Target and you'll see a little grading application at the bottom. At Dominoes, the mobile app lets you plug in and see exactly how quickly the workers put your pizza into the oven. It's not just them; this same trend is going on everywhere. Those feeds are then aggregated to give management the illusion that they know how things are going.

I would be interested in a tool that tracked this. The amount of code I write a day is as useful to me as the amount of bugs my code introduces.

Mind you, I would not be interested in comparing my daily code output to someone else's. But for myself working on one project, with the same language and coding methods, over a period of months, it could be useful.

It would also be interesting to track number of books read in a period of time, even though some books may take longer to read than others.

I could see PHBs firing the essential coders who write core parts of code because their line count is low, and bug rate is high etc. and keep the codemonkeys cause they write ten login pages a day.

Thus such a business employing this tool would surely tank or become like Microsoft, who need to use binoculars to the competition to define their metrics.

Reply on news.ycombinator.com