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