Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
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:
  • What crap (Score:5, Insightful)

    by Anonymous Coward on Thursday February 09, 2012 @11:39AM (#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?

    • by eldavojohn ( 898314 ) * <eldavojohn@@@gmail...com> on Thursday February 09, 2012 @11:48AM (#38983091) Journal

      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?

      • by gr8_phk ( 621180 ) on Thursday February 09, 2012 @12:43PM (#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 ;-)
      • by Anonymous Coward on Thursday February 09, 2012 @12: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.

      • - Consider a problem solver who spends most of the time helping others. That person can perhaps solve a problem in 5 minutes, which would have taken 2 weeks from a whole team.
        - Or an educator, who can turn bad programmers into good programmers by teaching them, thus increasing the development speed.
        - Or a person who can say "we don't need to spend half a year developing that, we can use this instead" and save a huge pile of money.
        - Or a person who invents a way to speed up the process and saves 1 hours a da

    • Re:What crap (Score:5, Insightful)

      by Anonymous Coward on Thursday February 09, 2012 @11:48AM (#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 (Score:4, Insightful)

        by hughbar ( 579555 ) on Thursday February 09, 2012 @11:54AM (#38983213) Homepage
        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.
        • by msobkow ( 48369 )

          You're just jealous that I peaked at 27,000 lines of code per day using my tools for a 2-3 month period. :)

      • I used to work on an online product support team... ha, ha what a travesty. The foreman used to - among other things - bash me for "typing too slow" and "thinking too much" over my replies when the other team members were swiftly and productively typing away at our customers.

        Oh yeah, pity that those touch typing heroes were constantly hitting the del key... metric morons.

        In life, you get what you ask for... if not worse

    • by dmomo ( 256005 )

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

      • I had a boss once who checked in code constantly. He was indeed one of the most productive members of the team, but the number of checkins far outweighed the actual productivity since he was also committing a lot of code to fix up his earlier commits. Ie, he checked code in before testing, then tested it immediately, then updated the code, plus he used the checkin as a means of backing up files sometimes. Whereas I'd wait until the code was working or at least in a workable form before checking in.

        There'

        • Re:What crap (Score:4, Insightful)

          by hazem ( 472289 ) on Thursday February 09, 2012 @02:56PM (#38986653) Journal

          > I'm a programmer but I don't spend all my day programming. There are long periods of time where I do no programming at all, I'm helping out others, answering questions,

          Imagine now you help five colleagues solve their problems - they get the credit because they did the commits, and you get fired for being unproductive.

          I once worked for a guy who said, "be careful what you measure - you'll get more of it".

      • Be careful what you measure, as that will be what people will do ...

        If you measure commits, with comments, then people will do many commits with comments,... the comments may not be useful, the commits may not be relevant, but that is what you measured so that is what they did ...

    • Re:What crap (Score:4, Insightful)

      by Marxist Hacker 42 ( 638312 ) * <seebert42@gmail.com> on Thursday February 09, 2012 @12:00PM (#38983323) Homepage Journal

      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 (Score:4, Insightful)

      by DaMattster ( 977781 ) on Thursday February 09, 2012 @12:05PM (#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.
      • 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 (Score:4, Informative)

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

        • by jdgeorge ( 18767 )

          Hey, you with the facts and reasons, stop it!

          Seriously, though, the interesting question is: If you are going to be evaluated on your job performance, would you prefer it to be done in part using an automated system as described in the patent, or completely by a manager who may have no effective way of understanding your programming work?

          • by PCM2 ( 4486 )

            Seriously, though, the interesting question is: If you are going to be evaluated on your job performance, would you prefer it to be done in part using an automated system as described in the patent, or completely by a manager who may have no effective way of understanding your programming work?

            Personally? I'll take the manager. Fuck the automated system.

            Why? Because the automated system isn't ever going to be given the authority to assign you promotions, or give you raises, or dole out work. The manager is still going to do those things, whether there's an automated system or not. The purpose of the system is to give the manager information by which to make decisions.

            What that means is, without the automated system, you have a silly, ignorant manager who doesn't know his job. With the system, you

            • by PCM2 ( 4486 )

              Ha! It just occured to me that I posted the above immediately after watching an entire half-season of The Wire. Folks might want to check out that show to see how things go when managers are encouraged to play the stats game.

    • Not close enough (Score:5, Insightful)

      by Asic Eng ( 193332 ) on Thursday February 09, 2012 @12:05PM (#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.

      • by uncqual ( 836337 )

        At least they are patenting it, which should prevent others from introducing this dumb idea.

        They may turn it into a commercial product with a nice glossy cover on it that any PHB can use without even knowing what a "commit" is, let alone the contents of said commits in his/her organization.

        Perhaps what is needed is a philanthropic organization to prevent problems like this. The organization could be funded by geeks' financial contributions and geeks could submit really bad ideas which should never see the

    • by mwvdlee ( 775178 )

      "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

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

    • by Jawnn ( 445279 )
      ...thus proving that you can, in fact, receive a patent on even stupid and worse-than-useless shit.
    • by msobkow ( 48369 )

      Personally I'd be really curious to see how IBM's system rates my work at http://msscodefactory.sourceforge.net/ [sourceforge.net]

      With manufactured code, often the only update is the header comment as to which version of the tool was used to produce the code, but at the same time, you'll find gems like me writing the GEL compiler and runtime in under a week. :)

    • 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?

      Heaven forbid that you should RTFA, or even the summary, so plow on with your prejudice. Nowere does its say that frequent check-ins would be used as indicating a good programmer. Quoth the patent:

      The data analysis component 433 may also include a comparison component 435 for comparing analyzed profile attributes of more than one developer... Determine any other valid statistical comparison between this user profile and other user profiles to find the standard deviation of a profile from the mean profile values. This finds users who may be at the extreme side of the average who may need to be highlighted for support or acclaim

      So, Alice and Bob are good programmers and check-in once a week. Charlie is a bad programmer and checks-in ten times a day. Perhaps his manager says to him Why don't you work more like Alice and Bob? They make less frequent changes. Perhaps you need to slow down a little?. Once you have data to analyse, you will

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

  • Tool for idiots (Score:5, Insightful)

    by Anonymous Codger ( 96717 ) on Thursday February 09, 2012 @11:42AM (#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 (Score:5, Interesting)

      by Hentes ( 2461350 ) on Thursday February 09, 2012 @11:46AM (#38983057)

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

      • When I was at RIT during the mid 1980s, the CS students knew better to stay away from the IBM recruiters.

        I did some co-op work at an IBM plant during those days (I was an EE not a CS). The new hires were top-of-the-class 4.0 GPA students. Some of them demonstrated beautifully that they were really good at college studies but absolutely terrible in the real world workplace.

        My dad was a manager there and he was competent with computers. He and his colleagues said most of the blame was laid squarely a
        • When I was graduating I had to work for my living and I worked for the hardware helpdesk at IBM. Apart from the very strict rules, the posters against espionage (we handled the calls for faulty typewriters for crying out loud) and the fact that we switched manager every 3 months and most people didn't last longer than the managers so they didn't even notice it, it was also the dumping ground for people they didn't want to fire but didn't want to retain in their old position either. I didn't really understan

        • by Hentes ( 2461350 )

          My dad was a manager there and he was competent with computers. He and his colleagues said most of the blame was laid squarely at HR. Managers would find a qualified candidate, then HR would submit resumes of other candidates who had 4.0 GPA grades and met "diversity" rules laid out by federal regulations.

          I'm not familiar with the hierarchy of IBM, since when does HR tell the management who to hire? In normal places HR only participates in the first part to weed out those that are not serious.

    • by Viol8 ( 599362 ) on Thursday February 09, 2012 @11:48AM (#38983089) Homepage

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

    • Not having this tool, managers will just reward the programmers who complain the most.
    • The part of it that gets me is that its the managers who allocate the work in the first place.

  • by Anonymous Coward on Thursday February 09, 2012 @11:42AM (#38982979)

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

  • by ccguy ( 1116865 ) on Thursday February 09, 2012 @11:43AM (#38983001) Homepage
    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 (Score:5, Funny)

    by will_die ( 586523 ) on Thursday February 09, 2012 @11:44AM (#38983023) Homepage
    Let IBM have the patents that way no other vendor will add theses to thier products.
  • Ineffective (Score:2, Funny)

    by Anonymous Coward

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

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

  • by spidercoz ( 947220 ) on Thursday February 09, 2012 @11:47AM (#38983067) Journal
    ...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!

  • Translation (Score:5, Funny)

    by davidbrit2 ( 775091 ) on Thursday February 09, 2012 @11:49AM (#38983119) Homepage
    "IBM Seeks Patent On Poor Management"
    • by cdp0 ( 1979036 )

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

  • by jellomizer ( 103300 ) on Thursday February 09, 2012 @11:50AM (#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.
    • 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 reso

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

      I think lots of metrics have been devised that provide useful information -- but only if the programmers don't know what they are, and only if the people interpreting the metrics have a clue. As soon as people know they're being measured they adjust their behavior to optimize the measurements, so unless you can measure exactly what you want to optimize (and software development is far too complex for this to be easy, and may be too hard for it to be possible), then any metric will ultimately be counterprod

  • by roguegramma ( 982660 ) on Thursday February 09, 2012 @11:51AM (#38983147) Journal

    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.

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

      • by sconeu ( 64226 )

        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.

        • They *should* be afraid to modify it. Even a bug fix can adversely affect some customers. They may have worked around and come to depend on a particular bug, and "fixing" it would adversely affect them. Even a code speedup can cause problems in the real world.

          If the paying customers are happy with the code, leaving it alone is a sound business decision. If you want to fix it, create a new version (or even a new product) that fixes all the known problems with the current code. After most of the c
      • 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 coder

        • by Altus ( 1034 )

          Also leads to a situation where incumbents have a financial reason to be defensive about their code. Try suggesting to your boss that something he wrote years ago has to be re-written if his bonus is riding on it.

          • Since his bonus is only a part of the current sales, perhaps that part of the code shouldn't be rewritten.

            Instead of spending your time rewriting code that is making paying customers happy, start with the current codebase and make a new product that will make you a large bonus. Re-invent the wheel only to get new customers. If you mess with the existing product, you might impact current customers, even if you make it better. The are many instances where a customer is dependent on a "bug", has worked
    • 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.

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

  • 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 (Score:3, Interesting)

    by doomday ( 948793 ) on Thursday February 09, 2012 @11:52AM (#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.
  • 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...

  • by account_deleted ( 4530225 ) on Thursday February 09, 2012 @11:55AM (#38983237)
    Comment removed based on user account deletion
  • by Sloppy ( 14984 ) on Thursday February 09, 2012 @11:58AM (#38983289) Homepage Journal

    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.

  • by Bucc5062 ( 856482 ) <bucc5062 AT gmail DOT com> on Thursday February 09, 2012 @12:00PM (#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.

  • 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 j

  • 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 int

  • 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 meaningle

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

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

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

  • by Sqr(twg) ( 2126054 ) on Thursday February 09, 2012 @01:10PM (#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.

  • I really don't see anything wrong with this, as long as it is used for what it is - a tool. A tool to have a rough gauge of what developers are up to. We don't throw out weigh scales because it isn't an accurate measure of a person's health, do we?

    If you have a good and competent manager she/he can use this tool as a rough measure to see what people are doing. Trends probably matter too. If you see a developer suddenly drop off in terms of commits, this is cause to look at other metrics and perhaps view

  • by mbkennel ( 97636 ) on Thursday February 09, 2012 @01:40PM (#38985179)

    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.

  • There is no measure of productivity that does not have huge flaws. We'd like to measure quality but there isn't even a reliable definition of quality.

    Other posters have mentioned that developers will game the system. That is true. Even if the metric is simply personal observation, people will exceptional and sometimes devious social skills will game the system. That is what office politics and the good old boy network are about.

    If trick is to combine subjective and object metrics (even if flawed). You

  • Apple tried this a long time ago [folklore.org] with predictable results. (well, predictable to most of us anyway)

  • and I know that lines per day, commits, Mountain Dews chugged don't work as a valuable metric. I know it's different for programmers, but in the rest of the world it boils down to "Get X done by this date." Sure there are status updates, but not daily monitoring of networks routed, cables pulled, systems setup, etc. It's like management is treating coders like data entry people. Just push some buttons and magic comes out! Woo hoo! Don't know how you guys deal with that crap.

Over the shoulder supervision is more a need of the manager than the programming task.

Working...