IBM Seeks Patent On Judging Programmers By Commits
theodp writes "How'd you like to be deemed unworthy of a job based upon a scan of your GitHub updates? That's what proposed in a newly-published IBM patent application for Automated Analysis of Code Developer's Profile, which proposes weeding out developer candidates for certain roles based on things like the amount of changes one typically makes with each commit, how frequently and regularly one makes commits, what hours of the day one makes commits, the percentage of commits with conflicts that one resolves, and the 'depth' of one's commit comments ('shallow', 'mid-range' or 'deep'). Big Blue explains that commit or repository interactions can be used to produce a 'conclusion report' that compares a developer to others who have profiles on the repository, which helps management 'avoid wasted time with ineffective developers."
The guy that spends a week finding a five year old memory bug, that no one has every been able to find is now ineffective, whereas a dweeb performing trivial refactoring is classed as a genius?
This is a tool for idiot managers who don't understand programming and who have no clue how to manage programmers, and who want to look like they're in the loop. There's no way I'd stick around in a job where I was judged based on this absurdity.
No sig? Sigh...
They're both full of people who are afraid to commit.
Let IBM have the patents that way no other vendor will add theses to thier products.
No... They are hoarding stupid patents so that they can sue anyone who uses these stupid rules!
Why? This is IBM we're talking about. They used to judge programmers on the number of lines of code generated rather then on the efficiency of said code.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Business methods are NOT inventions, they do NOT advance the sciences or useful arts, and SHOULD NOT BE PATENTABLE!
"I disapprove of what you say, but I will defend to the death your right to say it." - Evelyn Beatrice Hall, re Voltaire
That sums up the majority of IT managers I've ever worked for. Most of them were admin/business types who'd been moved sideways from other areas and they generally would have had trouble spelling "computer" , much less programming one. But yes, this will be perfect for those sorts of numbnuts who need an easy way to "measure performance".
The guy that spends a week finding a five year old memory bug, that no one has every been able to find is now ineffective, whereas a dweeb performing trivial refactoring is classed as a genius?
The examples are endless so I'll provide another that I 1) witness monthly and 2) have been on either side of. You have the programmer that, when presented with implementing a solution to a complex problem, sits down and draws out class diagrams on paper and erases and redraws while that is cheap and writes the code once many days later and makes small changes to it as it is tested/refined. You also have the programmer that dives right in, may well discover that this was a really expensive solution though easy to code and has it constantly sent back to him after testing only to have to rewrite major portions of it and/or realize then that he/she is reinventing the wheel leading to major changes to try to use another library and, well, this run-on sentence like their work could go on forever while your first programmer was done weeks ago. And who gets the major commit and repository score?
My work here is dung.
"IBM Seeks Patent On Poor Management"
...They used to judge programmers on the number of lines of code generated rather then on the efficiency of said code.
They had to change their metric, or programmers would stop using loops in order to get a raise.
Then the programmers will just change how they comment their code.
When I was doing consulting I got dinged because as part of my time breakdown I put Bug Fixes as a line item. After I got dinged for that (Because they didn't want to pay for faulty coding) I changed bug fixes to specification changes. They were happy with that. For the most part good employees what to be honest about their work, however if you make a system where honesty is punished, then people will start stretching the truth.
No one has really found a good way to evaluate a programmers efficiency, mostly because if they do their job right they are not doing the same thing every day so their output will very. There were attempts of measurements like Lines of code which meant programmers started to write more verbose code and doing more copy and paste and less objects and procedures. Then they try to measure by number of projects or sub projects they produced, so the experience developers will jump on and take up the quick and easy projects leaving the ones that require more work to the newbies. Then there reporting by bugs tracked later on, now this had the problem where the developers would take so much time to make sure there weren't any bugs reported that the product never left the shelf or put try and catches that jumped over errors cases and hid the fact the bug happened only to appear in someone else section of code.
Software Developers/Programmers do the job that computers cannot do. So it is difficult to use computers to monitor their performance just because their work is a lot less calculated.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Considering that IBM has initiated a global outsourcing program, starting in Germany, it is easy to see how automated judging of code quality can go wrong:
Outsourced coders tend to code much more to spec, not using their brain and being sensible, and if automated judging of code quality results in an increase of payments, they will add 10 lines of comments to a x+=1 if the automated judgement likes that.
In addition, when I'm finished finding some bug, very often the resulting code will be shorter than the offending code. This is consistent with the true and tried concept that lines of code are proportional to the number of bugs. I wonder whether automated analysis is smart enough to detect such activity.
Hey don't blame me, IANAB
This sounds like it belongs on thedailywtf.com. So would anyone who writes copypasta look good according to these statistics? Would people who write short, carefully considered, effective, reusable code look bad? This type of application has the effect of forcing people to start optimizing their code to maximize the metrics, rather than working to produce an excellent product.
Remember, if The computer company, who happens to hire a great many programmers, were not granted a monopoly on this technique for hiring programmers, then they would have no incentive to develop the technique.
If you don't grant this patent, why should IBM innovate ways to figure who to hire? What's in it for them?
It is only by forcefully preventing the other companies in the tech industry from doing things like this, for two decades, that technology as a whole can move forward.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I've encountered this thinking frequently: "we can't measure everything objectively, so we'll just measure something somewhat related - that's got to be better than not measuring anything."
Sounds reasonable, but is actually wrong and dangerous. Engineers will identify what you are measuring and will change accordingly - which skews the results. And worse some will not change out of a sense of obligation or pigheadedness - which also skews the results because others do. Even if the thing you measured originally had some correlation with what you *wanted* to measure - it will no longer do that once you start measuring.
At least they are patenting it, which should prevent others from introducing this dumb idea.
If you think these methods of rating programmers are faulty then this patent is good. Nobody will be able to use these faulty metrics (except IBM) because they are patented ;-)
15 years or more ago, I had a friend in a high-level consulting company (as in contract programming stars, not powerpoint pushers). Their usual m.o. was to pay 2x the going rate and expect 5x to 10x the productivity and brains.
They had a contract with IBM fixing bugs in I think AIX or something (lucrative and endless). They shared the bug data base with IBM's own workers, who were working on the same project.
Clever gits that they are, they mined the bug data base algorithmically to look for old bugs which were opened, had many people work on them unsuccessfully, but were eventually closed. They identified one IBM employee (out of dozens/hundreds) who was able to fix demonstrably hard bugs (that other employees had tried and failed to address) consistently.
So, they made him an offer he couldn't refuse.