

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

How would you feel if someone monitored various aspects of your work, such as<p>how many lines of code you write in a day,<p>business value of code you produce in a day (e.g. Pivotal Tracker points),<p>average “lifetime” of your code before it’s changed,<p>what percentage of your code is changed,<p>what percentage of code you write from scratch vs. changing others’ code,<p>when bugs are tracked,<p>what percentage of bugs are due to your code,<p>how many files you change,<p>what coding tasks you are good/bad at, AND<p>what languages you’re most/least proficient in.<p>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?<p>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?
======
kls
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.

~~~
mattm
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.

~~~
devs1010
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.

~~~
chris_dcosta
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.

~~~
kls
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.

~~~
devs1010
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

------
Natsu
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.

------
eaurouge
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.

------
LarryMade
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.

