Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IBM Seeks Patent On Judging Programmers By Commits

timothy posted more than 2 years ago | from the combine-with-eye-tracking dept.

IBM 182

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

cancel ×

182 comments

Sorry! There are no comments related to the filter you selected.

What crap (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38982919)

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?

What Multidimensional Crap! (5, Insightful)

eldavojohn (898314) | more than 2 years ago | (#38983091)

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?

So this patent is good! (3, Insightful)

gr8_phk (621180) | more than 2 years ago | (#38984137)

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 ;-)

Re:So this patent is good! (2)

mapkinase (958129) | more than 2 years ago | (#38984389)

May that's what IBM wants it for, to save humanity from stupid metrics...

Re:What Multidimensional Crap! (5, Informative)

Anonymous Coward | more than 2 years ago | (#38984325)

IBM employees get bonuses for submitting patents. Therefore there are always peeps at IBM cooking up some kind of crazy patent so they can get it past the patent board at IBM and get it submitted to USPTO and get their little bonus. The effectiveness of all this is all subjective and marginal. Why do you guys think IBM has the most number of patents.

Re:What Multidimensional Crap! (1)

Anonymous Coward | more than 2 years ago | (#38984403)

And you make the automatic assumption that they would rather see frequent commits with massive changes than a fewer number of commits with smaller changes?

They list the metrics used, I do not see any listing of good vs bad anywhere in the summary.

Re:What crap (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38983095)

Programmers will just figure out how to game the system and get good reviews for their checkins. That's what happened when they tried to institute a number of lines of code metric.

Re:What crap (3, Insightful)

hughbar (579555) | more than 2 years ago | (#38983213)

Yes, exactly, at a previous job where we were presented with a mad time-recording system, we ended up writing a client to deal with it. I'm sure Friday afternoon commit++ projects will flourish. This is another version of the idiocy of counting number of lines of code per day/month.

Re:What crap (1)

Anonymous Coward | more than 2 years ago | (#38983137)

And the developer automates trivial refactoring (think R# + VS macros) gets paid to do nothing while he "works" from home.

Re:What crap (2)

dmomo (256005) | more than 2 years ago | (#38983243)

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

If I spent a week doing that, there'd probably be hell to pay. Point taken, though.

Re:What crap (3, Insightful)

Marxist Hacker 42 (638312) | more than 2 years ago | (#38983323)

Or, for that matter, the other way around. The guy who finds the five year old memory bug is a genius, while the guy who is refactoring all the code to make it more maintainable and save developer hours in the future is now an ineffective dweeb.

Personally, I want both on my team.

Re:What crap (1)

haystor (102186) | more than 2 years ago | (#38983411)

And the guy who checks out the code base to put braces on the same line as the function; He's a hero, right?

Re:What crap (2)

Isaac Remuant (1891806) | more than 2 years ago | (#38983645)

if the guy's name is script, then yes.

Re:What crap (3, Insightful)

Call Me Black Cloud (616282) | more than 2 years ago | (#38983677)

No, because everyone knows braces go on a new line!

Re:What crap (1)

hazah (807503) | more than 2 years ago | (#38984583)

Gross!

Re:What crap (3, Insightful)

DaMattster (977781) | more than 2 years ago | (#38983413)

This is a poor idea because ultimately it is the quality of the code being committed, not the number of the commits. You can have a high number of commits with poorly written code that has buffer overruns, null pointer dereferences, and failure to manage dynamic memory properly. This rewards someone that is sly, not a good programmer.

Re:What crap (1)

INeededALogin (771371) | more than 2 years ago | (#38984119)

This is a poor idea because ultimately it is the quality of the code being committed, not the number of the commits.

Read the summary at least. This is about more than simply counting commits. This involves the quality of the commit meaning that if someone is having to modify those lines later or remove that commit etc. I think this is brilliant honestly. Your source control knows all modifications to the source tree and by what individuals. Analyze a developers impact on the codebase and you can derive that developers value to the organization.

Re:What crap (3, Informative)

kdemetter (965669) | more than 2 years ago | (#38984567)

I don't think it's a good idea too automate it, and it also shouldn't be used as a selection process, because then people start to be afraid of commiting, causing them to delay it, which will result in more merge conflicts.

On the other hand, it can be very useful at the end of a project, to discussed the lessons learned, since you have the full history.

As a developer, I want to code efficiently, and meet my deadlines.
I have a much cheaper suggestion : 'The Clean Coder' , by Robert C Martin .

Not close enough (4, Insightful)

Asic Eng (193332) | more than 2 years ago | (#38983417)

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.

Re:What crap (0)

Anonymous Coward | more than 2 years ago | (#38983541)

This one time, after three weeks of debugging, the solution was to move one debug log printf line a few lines up, above a lock.

It was a three mutex, three thread, deadlock which happened rarely in testing, but frequently in production. Three engineers working three weeks to narrow it down to code which hadn't been touched in years. Took another couple of days to convince the testing team that had fixed it.

Re:What crap (2)

mwvdlee (775178) | more than 2 years ago | (#38983925)

"Commit Judgement", from the company that invented "K-LOC" (http://en.wikipedia.org/wiki/Source_lines_of_code).

Bad: Fixing a bug by fixing the single line of code that caused it.
Good: Fixing a bug by wrapping the entire routine in a large if..else.. branch for handling the specific case of the bug.

Bad: Commenting a commit with "Fixed bug #123; memory for property "foo" not released on destruction of a "Bar" instance."
Good: Committing with "I spent all day looking for this weird thing that happenned whenever an object of the class in this sourcefile was no longer being used where allocated ram was no longer available to other objects. Turns out that when the garbage collector got around to do it's thing one of the public variables just stuck around".

Bad: Fix a bug, test, tweak fix, test, commit fix.
Good: Fix a bug, commit fix, code crashes, fix bug again, commit fix, some minor detail was still missing, fix missing bit, commit, add some comments, commit, test, turns out the bug was in a different sourcefile, revert fix, commit, fix actual bug, commit, add commens, commit, test, tweak fix again, commit.

Re:What crap (1)

mapkinase (958129) | more than 2 years ago | (#38984361)

The whole movement "replace humans everywhere" is idiotic. Biocomputing centers getting rid of curators, oral exams replaced by idiotic choice tests, etc, etc.

Replace humans where no choice is involved. Once the choice is involved, programming becomes increasingly stupid and prone to errors.

Re:What crap (0)

Anonymous Coward | more than 2 years ago | (#38984405)

Patent application:

Description: A Method of determining Managerial Incompetence by measuring their utilization of automated performance measurement systems...

There are just so many things wrong with this concept. For one thing, my commit patterns fluctuate wildly, in large part depending on how paranoid I am, but also because "Hey, it's been 2 weeks since I saved any of this", versus "I'd commit this for safety reasons, but it's in such a mess right now that it would only pollute the archives.

Whenever Management start resorting to things like this it screams trouble. It generally means that a false efficiency has been achieved by not having a low enough manager-to-grunt ratio that people can interact directly or that the manager is too distracted to interact with employees or both.

  And, of course, the first thing everyone does is figure out how to game the system. Which by and large is something that the "Wallys" are more diligent at than the actual productive people.

The final failure that comes from reliance on bean-counting systems is that only visible beans get counted. As with all formalized tests, the problem domain is artificially restricted. There may be all sorts of reasons for alarm visible to managers who are in close touch with staff, but for those who rely on tests, the problems don't exist until something critical breaks.

We all know the classic example: call centers whose primary metric is how fast an agent can get a customer off the line. Even if the customer ends up swearing never to do business with that company again. And the hopeless cases where the situation is compounded by shoving "satisfaction surveys" at the customer, who all too often either ignores them or says whatever will get them off the line quickest.

I'd have expected better from IBM (1)

Viol8 (599362) | more than 2 years ago | (#38982943)

The number of commits or lines of code written is not indicative of how good a programmer is. What matters is whether they can deliver a working, efficient program to spec to the deadline. Aside from that - what happens if said candidate doesn't commit any code on public repositories - will IBM just bin his resume without even bothering to interview? This is just so absurd I had to check my watch to make sure it wasn't April 1st.

Re:I'd have expected better from IBM (1)

Anonymous Coward | more than 2 years ago | (#38983027)

It's a management tool. I already use FishEye to introspect on these topics. I don't use it to get rid of people, but I do use it to get insight into who needs guidance, whose work might need secondary vetting, etc.

Re:I'd have expected better from IBM (1)

Hogmoru (639374) | more than 2 years ago | (#38983199)

Yes, the job has to be done, but I don't see how a full-automatic system can do it. It requires knowlege about the project, what's going on, etc. And yes there are developers who are really bad at committing code: writing helpful comments, but also paying attention to what the "diff" will look like (i.e. avoid slipping a critical change in the same commit as a refactoring, or at least explain it very cleary to help locate it).
This is the project leader's job to monitor this, and talk with developers who need to make progress on this...

Re:I'd have expected better from IBM (1)

Viol8 (599362) | more than 2 years ago | (#38983233)

Sounds like the only thing that needs vetting is the idiot who hired someone as clueless as you in the first place.

Re:I'd have expected better from IBM (3, Insightful)

JAlexoi (1085785) | more than 2 years ago | (#38983039)

No... They are hoarding stupid patents so that they can sue anyone who uses these stupid rules!

Re:I'd have expected better from IBM (2)

w_dragon (1802458) | more than 2 years ago | (#38983197)

That's a good thing, right? Keeps other companies from being stupid?

Re:I'd have expected better from IBM (0)

Anonymous Coward | more than 2 years ago | (#38983419)

This ought to be rejected as unpatentable. Did we learn nothing from In re Bilski?

Re:I'd have expected better from IBM (3, Informative)

Kenja (541830) | more than 2 years ago | (#38983055)

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.

Re:I'd have expected better from IBM (3, Funny)

bkmoore (1910118) | more than 2 years ago | (#38983123)

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

Re:I'd have expected better from IBM (0)

Anonymous Coward | more than 2 years ago | (#38983409)

Don't you mean 'iWatch'?

Tool for idiots (5, Insightful)

Anonymous Codger (96717) | more than 2 years ago | (#38982977)

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.

Re:Tool for idiots (4, Interesting)

Hentes (2461350) | more than 2 years ago | (#38983057)

This exactly. If you can't hire "efficient" coders, it might be a clue that you need more efficient managers.

"managers who don't understand programming" (3, Insightful)

Viol8 (599362) | more than 2 years ago | (#38983089)

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

Re:Tool for idiots (2)

ShavedOrangutan (1930630) | more than 2 years ago | (#38983251)

Not having this tool, managers will just reward the programmers who complain the most.

Re:Tool for idiots (0)

Anonymous Coward | more than 2 years ago | (#38983491)

No problem. I can adapt. In fact I can think of many ways of doing useless commits every day. I will even automate the process. Do they pay bonuses to the programmers with the most commits ?!

What do eHarmony and IBM have in common..... (5, Funny)

Anonymous Coward | more than 2 years ago | (#38982979)

They're both full of people who are afraid to commit.

And here it goes... (1)

Anonymous Coward | more than 2 years ago | (#38982983)

So how many one line changes can I commit per day before someone yells "ENOUGH!!"?
I know too many 'hero' developers that would surely take advantage of this setup.
What if my commits are simply being done because I'm fixing bugs put in by someone else who's doing commits that are bug-ridden?
Yes I know a 'true' developer won't check in code that hasn't been unit tested....guess what, it does happen, and it's those developers who like to see themselves as pounding out 1000s of lines of code that make the difference, not the quality.

This is brilliant (0)

trunicated (1272370) | more than 2 years ago | (#38982997)

Because all of my commits include all the documentation I write, and are completely available to the public.

What is more brilliant is (0)

Anonymous Coward | more than 2 years ago | (#38983195)

my patent on estimating commenter IQ based on (in)ability to differentiate between the Subject and the Comment fields.

Well, who's gonna code this? (2)

ccguy (1116865) | more than 2 years ago | (#38983001)

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 :-)

Good (4, Funny)

will_die (586523) | more than 2 years ago | (#38983023)

Let IBM have the patents that way no other vendor will add theses to thier products.

Re:Good (0)

Anonymous Coward | more than 2 years ago | (#38984239)

Then every time your CIO goes for an afternoon on the golf course with the IBM drone your can sweat your $priv_part off.
(Worse, you can wait for MS to implement an even worse scheme badly, and the CIO will have to have it even without the afternoon on the golf course.)

I will commit every other line (0)

Anonymous Coward | more than 2 years ago | (#38983035)

See how you like it!

Ineffective (2, Funny)

Anonymous Coward | more than 2 years ago | (#38983041)

"which helps management 'avoid wasted time with ineffective developers.'"

Does it also help developers avoid wasting time with ineffective management who use stupid metrics?

I'm going to patent... (5, Funny)

spidercoz (947220) | more than 2 years ago | (#38983067)

...judging companies by the number of bullshit patents they file.

Business methods are NOT inventions, they do NOT advance the sciences or useful arts, and SHOULD NOT BE PATENTABLE!

Obvious Flaw (1)

Anonymous Coward | more than 2 years ago | (#38983079)

How do you measure the value of a commit when tracking down a one-line bug can take a very long time to find? I don't get paid because of my ability to write massive amounts of code... I get paid because if there is a bug, I am the only one who can track it backwards and find where to fix it.

So IBM is a TPS report hell hole? (0)

Anonymous Coward | more than 2 years ago | (#38983087)

So IBM is a TPS report hell hole? and they want to have auto manager as well. So If I work at IBM this will just may me do the minimum amount of work not to get fired.

reasonable approach (0)

Anonymous Coward | more than 2 years ago | (#38983117)

I've done the same analysis myself for decades, but manually. Never had to do it frequently enough to consider automating it. It does give some useful insights.

Some developers do infrequent big checkins, others do many tiny checkings on the same subject. I don't know which approach is better, the first batches a bunch of little changes and the second doesn't, otherwise theyr'e similar. Some developers add tons of comments to everything. One thing this could notice is band-aids: a developer who makes many tiny changes in many files simultaneously is more likely to be doing a correct fix than one who checks in one block in one file. Another interesting profile is a change that rearranges a lot of code and ends up making the code smaller.

On the other hand .. (1)

roguegramma (982660) | more than 2 years ago | (#38983261)

.. many tiny changes in many files indicates that concerns have been incorrectly separated in the pre-existing code, which might have been written by the same developer.

Translation (4, Funny)

davidbrit2 (775091) | more than 2 years ago | (#38983119)

"IBM Seeks Patent On Poor Management"

Re:Translation (1)

cdp0 (1979036) | more than 2 years ago | (#38983535)

This has the potential of bringing them more money than the rest of their business, then.

Re:Translation (0)

Anonymous Coward | more than 2 years ago | (#38984105)

If you know something is bad business but find suckers to sell it to, go ahead - that's the spirit of the free market.

Good that they're patenting it... (1)

Anonymous Coward | more than 2 years ago | (#38983131)

I wouldn't want anyone else to use this idea...

I know fantastic developers with wide ranging practices on commit size, frequency, length of commit comments. While I disagree with many of them, they still produce great software.

Re:Good that they're patenting it... (0)

CanHasDIY (1672858) | more than 2 years ago | (#38983405)

I wouldn't want anyone else to use this idea...

That's pretty much how I thought of it as well.

And I'm not even a programmer.

So once the algorithm is made... (5, Insightful)

jellomizer (103300) | more than 2 years ago | (#38983135)

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.

Re:So once the algorithm is made... (1)

Maximum Prophet (716608) | more than 2 years ago | (#38984011)

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.

I've often argued this with managers w.r.t. time estimates. If I know how long something will take, it's because I understand it and have done it before. If that's true, most likely, I can automate it so that it takes almost no time at all, i.e. scp foobar user@newmachine:/opt/productname/foobar

If I don't understand something yet, and I've never done it before, then right now, my estimate is infinite time, because there's a chance the current system won't handle the new specs using the available resources. I've even had exchanges like this:

  • Manager: How long will it take?
  • Me: ASAP
  • Manager: I need to know if I will have to put additional resources on the project.
  • Me: We're there. Are there any more resources?
  • Manager: No
  • Me: Ahhhg

IBM, Outsourcing and auto judging of code quality (3, Insightful)

roguegramma (982660) | more than 2 years ago | (#38983147)

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.

Re:IBM, Outsourcing and auto judging of code quali (1)

rrohbeck (944847) | more than 2 years ago | (#38983397)

+1.
Getting rid of crap and making things more consistent is worth a lot more than adding tons of code that trigger Coverity warnings or need to be refactored or even rewritten later. Programmers who produce tons of LOC are rarely good in my experience. A few weeks ago I spent about a week figuring out a truly hairy bug and added about 10 lines.
I found that longevity is a good metric. Code that doesn't need to be touched again because it just works is good code.

Re:IBM, Outsourcing and auto judging of code quali (1)

sconeu (64226) | more than 2 years ago | (#38983897)

Code that doesn't need to be touched again because it just works is good code.

The flip side of that is code that doesn't *get* touched because everyone is afraid to modify it.

Re:IBM, Outsourcing and auto judging of code quali (1)

Maximum Prophet (716608) | more than 2 years ago | (#38984223)

I found that longevity is a good metric. Code that doesn't need to be touched again because it just works is good code.

Quick, patent your process.

This sounds like a great idea that you could even base bonuses on. You get a point for every line of code that is still in production. After the points are added up, the bonuses are based on the relative percentage of all points.

Question: Do you care if you have someone that has amassed so many points that he doesn't have to work anymore?

If bonuses are based on a percent of sales, then consider the end case where you've got a profitable product that none of your coders have touched in years. Do you care? If sales fall, so will bonuses, providing an incentive to invent something new.

Under this system, newbies would have to code new apps that provide additional revenue.

Re:IBM, Outsourcing and auto judging of code quali (0)

Anonymous Coward | more than 2 years ago | (#38984497)

Assuming that the evaluated code chunks are equally used...

Re:IBM, Outsourcing and auto judging of code quali (1)

Marxist Hacker 42 (638312) | more than 2 years ago | (#38983687)

Hmm..and in keeping with it's sometimes hard to tell the difference between a feature and a bug, one could also say that the number of lines of code is proportional to the number of features.

Re:IBM, Outsourcing and auto judging of code quali (1)

powerlord (28156) | more than 2 years ago | (#38984641)

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.

If it gets Outsourced coders to use comments, then I'm all for it. Too often that tends to be the thing they skip the most. They are too involved in writing the code, too green, or under too much pressure to write and be done, that comments often are thrown under the bus.

I only commit one time. You insensitive clod! (0)

Anonymous Coward | more than 2 years ago | (#38983163)

I never do incremental commits. I only commit fully completed applications into the repository. You insensitive clod!

Any single number will be fudged (1)

ElmoGonzo (627753) | more than 2 years ago | (#38983173)

Years ago I heard of a group of C developers who were judged by a metric which was Reported Bugs / Lines of Code. Lines of Code was determined by a compile time count of lines compiled. Developers started adding extraneous .h files which increased the LoC value and lowering the metric to a releasable state. You want more commits? Here are more commits. I changed one character. Commit!

The Daily WTF (3, Interesting)

doomday (948793) | more than 2 years ago | (#38983175)

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.

brilliant (0)

Anonymous Coward | more than 2 years ago | (#38983177)

IBM patents the idea and then (hopefully) refuses to license it. so now when your boss tries to use that as a metric you can tell HR and Legal and end that bad idea quickly

Judging Organizations by Patent Applications (1)

RevEngr (565050) | more than 2 years ago | (#38983191)

My invention is a system and method for the Automated Analysis of Patent Filings to determine which companies are submitting things that are obvious, anticompetitive, practically worthless, and/or generally inclined to stifle rather than spur innovation. These factors will be used to produce a "conclusion report" that compares a company to others in the field to help job-seekers 'avoid wasting time with trolls and bloated relics from days gone by.'

Hah! (1)

decipher_saint (72686) | more than 2 years ago | (#38983203)

This reminds me of metrics that awarded lines of code, as if programming were factory piecework (well, maybe at IBM, I don't know).

The only metrics that are important are:
-Does the software work
-Is it maintainable
-Is it done on time

Everything else is balls, or y'know fuelling management paranoia to sell IBM metric tools...

Re:Hah! (2)

rrohbeck (944847) | more than 2 years ago | (#38983455)

Judging programmers by LOC is like judging airplanes by weight. Who said that?

Re:Hah! (1)

BinarySolo (1951210) | more than 2 years ago | (#38984229)

Bill Gates, I believe.

Sun used to do this (1)

Anonymous Coward | more than 2 years ago | (#38983227)

Posting anon, sorry. But I did work at Sun Microsystems for a good number of years and it was very much a system that rewarded those that committed (cvs, "putbacks/bringovers", whatever tool of the day was used) often. I always felt that my code commits were being judged in frequency and comparitively.

I don't know if things got better or worse when Sun "merged" with Oracle. I was not there at that point; but before then and just before then it kind of started to suck in terms of code devel politics.

Re:Sun used to do this (1)

Isaac Remuant (1891806) | more than 2 years ago | (#38983735)

That's something not many people is discussing here due to the lack of effectiveness of the "solution" but an implementation of such a system shouldn't be patentable. It's not inventive. A bad idea but an [b]obvious[/b] one.

Re:Sun used to do this (1)

Isaac Remuant (1891806) | more than 2 years ago | (#38983767)

arghh... bbcode instead of html... I'm ashamed of myself.

That's how we roll here . . . (2)

mmell (832646) | more than 2 years ago | (#38983237)

Worst. Metric. Ever.

But we prize form over function. Server down - that's okay. Form not completely and correctly filled out? That's a FIRING offense.

They need the incentive (5, Insightful)

Sloppy (14984) | more than 2 years ago | (#38983289)

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.

19th Century is calling (2)

Bucc5062 (856482) | more than 2 years ago | (#38983311)

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.

Anti-FOSS patent, shame on you, IBM (0)

Anonymous Coward | more than 2 years ago | (#38983321)

If this patent were to come into common use, it would impact on commits made by FOSS community members. Anyone making public commits under their real names or under well-known pseudonyms would be continuously aware that at some future time, some moron from some HR department will be processing their commit history and potentially limiting their career prospects.

That's no way to support open source, IBM. In fact it would be a good reason to make a project closed source.

Among the many clever people at the company, it seems that there are some clueless patent writers who can't foresee the future impact of what they propose.

Once again for the people that haven't gotten it (1)

cdrguru (88047) | more than 2 years ago | (#38983367)

Everything you do on the Internet is available for inspection and analysis. Sooner or later, someone will come up with a methodology for analyzing photographs on Facebook and Picasa that indicate a person's personality type. And this will be used to filter job applicants.

If you post it online, it will be used to rate you in some fashion. It may be just an HR tool for sorting resumes, or it may be something that is used to select between candidates.

Someone I know just went through about four months of a job working its way through a large company where the job changed from a contractor job (that he was approved for) to a employee position. There were four candidates and four different managers each rated a different person as the top contender. HR took this as an indication that there was no "outstanding" candidate and nobody got the job. The hiring manager was pissed but there was nothing that could be done about it. This is how hiring works in large companies with unions. The actual hiring manager has zero control over the process.

But if you haven't been paying attention, everything you do online will be collected, collated, inspected, analyzed and reported on. There will be services (probably are already) for researching job candidates, prospective spouses, potential roommates, etc. that will use this information to build up a profile that will be useful to some. Is it all BS? Maybe, but people will pay money for it and therefore it is going to happen.

Well, at least it's an easy system to game... (1)

gestalt_n_pepper (991155) | more than 2 years ago | (#38983387)

Computers are stupid, much like the folks at IBM that conceived this idea. In the end, all programming metrics are subjective.

Low scoring (i.e. few commits): A new, unique and briliant algorithm that models molecular interaction 10000x more accurately and only requires 10 lines of code and some trivial unit tests.

High scoring (i.e many commits): Changing the labels in 1000 dialog boxes to correct for proper case, making a commit for every 10 changes.

There is simply no way, absent of meaningful artifical intelligence, to measure whether the changes were difficult or meaningful. And, sorry to say, guys, Watson isn't there yet.

Recursion (1)

TBerben (1061176) | more than 2 years ago | (#38983393)

Does the analysis software scan it's own source code repository, firing the programmers who have contributed too little to its creation?

From the company that brought you KLOCs (0)

Anonymous Coward | more than 2 years ago | (#38983439)

I like IBM, but they hiccup like anyone else. I remember them famously measuring programmers by KLOCs back in the day -- 1KLOC = 1,000 lines of code. Obviously the more code you write the better a programmer you are, right? I think commit mining, like many metrics, will provide interesting information, but I'm sure it's far from a complete view. I'm glad to see that they're looking at comments and some other meta information, rather than just number of commits. Still there's much to do... complexity vs. simplicity is a tough trade off -- which is "better"? A "deep" comment may be unnecessary if an elegant solution exists, that sort of thing.

Can we do this to lawyers? (1)

Required Snark (1702878) | more than 2 years ago | (#38983443)

Is there some way this kind of bullshit metric could be applied to lawyers? Perhaps take the number of pages generated and compare it to the number of hours in the courtroom, or the outcome of the case,

I figure that this class of mind numbingly stupid patent results from the bastard mating of lawyers who want to patent all human activity with managers who want to have so many patents that they will never be blamed for not having a legal rabbit to pull out of the hat.

So if someone comes up with a meaningless way to judge the "output" of lawyers and makes their lives a living hell, it would be appropriate "justice". They would get to experience the kind of crap that they have been shoveling into the lives of normal humans.

Re:Can we do this to lawyers? (1)

dna_(c)(tm)(r) (618003) | more than 2 years ago | (#38983627)

Is there some way this kind of bullshit metric could be applied to lawyers? [...]

So if someone comes up with a meaningless way to judge the "output" of lawyers and makes their lives a living hell, it would be appropriate "justice". They would get to experience the kind of crap that they have been shoveling into the lives of normal humans.

[Number of word processor manual save]*Square root of[Number of vowels typed in last 24 hours]

It measures brain activity and penalizes copy/paste, template stuff like headers/footers, standard letters with a few fields changed per client...

Re:Can we do this to lawyers? (0)

Anonymous Coward | more than 2 years ago | (#38983805)

the metric that matters to most lawyers is billables. Desired outcomes for clients is secondary, in as much as it affects billables. It is OK for lawyers to lose their cases (but not all the time!), as they still get paid. Client may get reamed, paying costs for losing, but the lawyers all get paid.

There is one answer to this : (0)

Anonymous Coward | more than 2 years ago | (#38983461)

Any management worth its salt knows that a hard to reproduce one liner code which takes many hours of hard work to trace back , is much more worth than your programmer monkey which commit lot of code with refactoring some stuff. If your management don't udnerstand it and introduce such "measuring" : game it.

Awesome! (0)

Anonymous Coward | more than 2 years ago | (#38983469)

As a developer I think this is great, because it weeds out the employers who don't understand software development (those that feel they need this tool).
I don't want to work for a company that would use this tool, so it would go a long way in filtering them out for me. :)

The fallacies of IT metrics (1)

smooth wombat (796938) | more than 2 years ago | (#38983581)

Infoworld had an article about the fallacies of IT metrics which I copied and have saved. If you want to read why measuring code in lines per day/month is the wrong metric (even if you already know why it's wrong), this article gives more reasons.

The link to the article is this one [infoworld.com] .

It should be mandatory reading for anyone who utters the term 'metrics' in a meeting.

Reminds me of working in a call centre (0)

Anonymous Coward | more than 2 years ago | (#38983655)

The tech support call centre I worked at gave first crack at choosing a shift (it was a 24/7 operation) to the people with the lowest call times.

It was fun gaming the system to figure out ways to get customers to hang up on you without them being angry at you. My favourite was asking them to unplug their phone in case it was the problem. Yes, go ahead and do that now. *click* Ahhh, morning shift.

On the Bright Side (0)

Anonymous Coward | more than 2 years ago | (#38983795)

On the bright side they are patenting this, so for 20 years only IBM will be able to judge you like this.

performance metrics at IBM (1)

fliptout (9217) | more than 2 years ago | (#38983851)

Every time I read a story like this about performance metrics at IBM, whether it be git commits/KLOCs written/whatever, I have to wonder what kinds of practices engineers there develop. Does engineering quality suffer as a result of gaming the metrics? Are really good engineers helped in their professional development by these metrics, or are they hampered? Are they driven away? Personally, this kind of environment sounds dreadful, but I'm curious what IBMers would have to say about it.

You can patent metrics? (1)

stoicfaux (466273) | more than 2 years ago | (#38984233)

Seriously, can you really patent the idea of taking metrics in order to evaluate performance? Even with the idea of software patents, that seems overly broad.

Missing the point - Artificial Intelligence (0)

Anonymous Coward | more than 2 years ago | (#38984245)

I think everyone here is missing the point. I imagine IBM would like to build the intelligence correlating checkin's to fixed bugs. If the issue gets re-opened multiple times and the same code gets checked in repeatedly w/o significant progress in resolving the issue, IBM could then correlate it to the performance of the developer. I do not think the system would be simplistic to judge just by commits. Rather it would be smarter to associate commits with fixes and bug resolution/system enhancements. If they can quantify these various metrics, I don't see why they cannot begin to build some metrics about the developer/development process itself.

The important part.... (1)

tilante (2547392) | more than 2 years ago | (#38984269)

It looks like the important part here is paragraphs 0115 - 0116:

[0115] In conclusion, a method, computer program product and system are described for assessing the habits and understanding a developer's coding style and general day to day cycle that automates the process of estimating the relevant role of development this developer would suit. This contributes to any assessment of a member of a coding team's suitability to a project and the current efforts of team members already in place. For instance, a determination can be made as to whether a developer is suited to a specific development style and role in a specific project. This could lead to teams becoming more efficient, productive and delivering faster with better code. It could also lead to happier developers working on more appropriate projects.

[0116] The approaches described more fully herein, avoid wasted time with ineffective developers, thus increasing productivity and efficiency of processes. The approaches described more fully herein, may also result in building a balanced, accurate understanding of developer(s). The approaches set out more fully herein also avoid the problems of having to rely upon assessing a person for their suitability to a development methodology solely by interview, appraisal or study of their previous work, which is a very time consuming process for management to undertake. For instance, there may be many candidates to evaluate and such manual processes can result in a heavy burden on time, accuracy of results and money.

[0117] The described method and system provide a number of advantages over existing assessment techniques. As an example, a small agile development team may require frequent synchronization between developers and the central repository, and not require change commentary for code submissions. The user profile for a possible addition to the team could be studied and very quickly a conclusion could be drawn about the specific persons coding style and whether it suits the current team and the team's requirements. This conclusion is based upon the described algorithms and study of the appropriate data.

So, in other words, the idea is not to say "There Is One Ideal Way to Do Commits!" but rather to use the metrics this algorithm generates to see if a developer's way of working will integrate well with an already-established group. If IBM actually uses the system this way, it might actually make some sense.

woot (0)

Anonymous Coward | more than 2 years ago | (#38984345)

lulz, 1999, http://www.elbit.fi

Ah PMs (1)

jimmerz28 (1928616) | more than 2 years ago | (#38984397)

Maybe one day they'll be able to patent managers that actually manage and get to know their programmers.

But really I mean by then there will be no such thing as managers and they'll all be Scrum Masters and power will go to the development team itself.

K-LOCs! (2)

Sqr(twg) (2126054) | more than 2 years ago | (#38984609)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>