IBM seeking commit-judging patent to assess developers?
Despite being slightly vague in how the metric will be defined, IBM have filed a patent entitled ‘AUTOMATED ANALYSIS OF CODE DEVELOPER’S PROFILE’. But what does that mean?
Big Blue seems to have angered the developer community again by filing yet another patent, but this time it’s much more personal.
The ‘Automated Analysis Of Code Developer’s Profile‘ patent was filed back in August (yet gathered momentum yesterday) and has the following raison d’etre in its abstract:
The automated analysis of a code developer’s profile comprises gathering data relating to code repository updates by a developer, analyzing the gathered data to determine profile attributes of the developer to provide a behavior analysis of the developer and analyzing, using a microprocessor, the profile attributes of the developer with respect to role descriptions
So what exactly does that entail? Broadly speaking, it seems that IBM is trying to patent a metric that monitors developers’ commits to a repository, like on Github and use said metric to analysis their performance.
Could this metric be used then to eliminate prospective candidates for a job role based on the amount of changes per commit? Or could it even be used to measure how frequently and regularly one makes commits? Perhaps the percentage of commits with conflicts that one resolves? Even the ‘depth’ of one’s commit comments (‘shallow’, ‘mid-range’ or ‘deep’) could be analysed. The possibilities are endless.
This surely sets a dangerous precedent to create a method of analysing a developer’s worth through repository changes, when each individual case is so difficult to judge. It’s certainly haphazard to judge someone based on lines of code/hours put in, if those lines of code cause more trouble in the long run to the project.
Other variables come into play here. Some may use Github for their own side projects or create joke code, would these people be penalised? It’s all a bit too murky.
IBM argue within the background of this patent that:
Managers and team leaders in the field of computer code development often have little understanding of their development team’s coding habits and profiles. Developers work in various different ways and a certain developer’s habits may or may not be suitable for the specific project that the certain developer is working on. Accordingly, trying to determine how a member of a team fits in with the chosen development methodology can be difficult.
The approaches described more fully herein, avoid wasted time with ineffective developers, thus increasing productivity and efficiency of processes.
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.
The first part of that appears correct. This patent reeks of some scheme dreamt up by a manager who doesn’t know how to deal with his/her troops, and needs a ‘foolproof’ method of casting the deadwood out of their team in the easiest way possible. But using it as a method to eliminate potential candidates early on could be incredibly risky, and if we’re honest, feels as another way to save time and money in the hiring process.
As expected, news of this patent swirled round forums and sites. Slashdot in particular provided some interesting discussion. Some dismissed this out of hand immediately, stating that IBM’s penchant for patenting means that this idea won’t be taken by anyone else (and that it was probably a good thing they were patenting this method). Others were deeply critical of IBM’s policy.
‘Anonymous Coward’ posted
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.
Another echoed his feelings:
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 the main worry – introducing this analytic method could see many developers play the system to avoid the flack. Quite possibly the most worrying aspect is the automation of a developer’s commitment. It’s fairly impossible to measure it objectively.
What we can hope is that IBM are patenting this method purely to stop others from doing so, and have no intention of using it. This isn’t a tool for efficient coders but what we need is efficent managers with their heads screwed on.