Slashdot Mirror
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.
I assume this is just a theoretical analysis. Well, eventually a team of coders will get to do it... and guess what, they'll use it of themselves.
:-)
I expect this team to have lots of backstabbing fun
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!
"which helps management 'avoid wasted time with ineffective developers.'"
Does it also help developers avoid wasting time with ineffective management who use stupid metrics?
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.
That's a good thing, right? Keeps other companies from being stupid?
But we prize form over function. Server down - that's okay. Form not completely and correctly filled out? That's a FIRING offense.
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.
How do you patent this type of shit. It's an idea, a process, not a product. Even if it were a "product" how does it even come close to being original. Management has been using these bullshit techniques to attempt to measure "performance" since the damn 60s.
Of course it will get a number, because the USPO has lost touch with reality. Everything is original, there is no prior act, no idea is far fetched enough to not get a patent. Hell, I remember when "lines of code" was the measurement of work. As I recall, 25 lines a day was the average. Tripe!
If management looked at development, not as a manufacturing job, but what it really is, craftsmanship then we could do away with bullshit patents like "count the number of times Joe/Jane programmer commit changes". We craft/build programs based on specifications and were we to meet those requirements, then we did our job. Measure completion rates, over/under completion times, quality of the product, but for Heaven's Sake, grow some brain cells and get out of the 19th century mentality of counting widgets made per day as productivity.
Life is a great ride, the vehicle doesn't matter
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.
Judging programmers by LOC is like judging airplanes by weight. Who said that?
thegodmovie.com - watch it
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 ;-)
In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand lines of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 50K-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS/2, how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less K-LOC. K-LOCs, K-LOCs, that's the methodology. Ugh! Anyway, that always makes my back just crinkle up at the thought of the whole thing. -- Steve Balmer.
Not much has changed at IBM since the 70s, apparently.
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.
Your comment got modded "Funny". I'm uncertain if that was your intent but I can assure you that when being paid by LOC, their programmers did in fact unroll loops.
"The ferrets, they're every where I tell you!"