Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
IBM Patents Programming Stats Your Rights Online

IBM Seeks Patent On Judging Programmers By Commits 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."
This discussion has been archived. No new comments can be posted.

IBM Seeks Patent On Judging Programmers By Commits

Comments Filter:
  • by Kenja ( 541830 ) on Thursday February 09, 2012 @12:46PM (#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.
  • by Anonymous Coward on Thursday February 09, 2012 @01:52PM (#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 crap (Score:4, Informative)

    by kdemetter ( 965669 ) on Thursday February 09, 2012 @02:07PM (#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 .

Honesty is for the most part less profitable than dishonesty. -- Plato