In a world that runs on terabytes upon terabytes of data, placing a number on and quantifying items has become little short of a necessity. And why this need to associate numbers with everything? So that the goals of efficiency can be achieved. In the paradigm of an organisation, measurement of the members' productivity is inevitable. Everybody is constantly monitored by one or the other. This naturally means that over time, metrics have been devised for quantifying productivity. But it isn't an easy task, especially when it comes to certain classes of members. Case in point? Developers. Or more broadly, people whose work involves writing code - call them what you may.
Why is it necessary?
To start with, the primary and most obvious reason assessment of productivity is necessary, comes from a managerial standpoint. In a system that's growing ever so closer to an incentivised culture, numbers become relevant to take calls on who gets the perks, or who gets to climb up the rungs of the corporate ladder.
While organisations more often than not choose the popular policy of using time as a metric to decide who gets the nod, it is far from the best metric. Yes, people who have spent long periods in an organisation tend to know better, the same logic cannot be applied to pre-dominantly skill-based roles like that of a developer. All roles are skill-based but roles like that of a developer are unique in a way that someone with 6 months worth of experience might turn to be leaps and bounds better than someone with about 2 years of experience since the knack or acumen for coding the right solution to a problem isn't a skill that can grow over time alone - some people are simply better at it perhaps due to innate skill or the sheer amount of work they have put in.
We have, therefore, no other option but to accept that judging a developer's productivity is of paramount importance. Beyond the awarding of perks, this assessment is necessary for yet another reason. Someone who is showing stagnation or worse a dip in productivity needs to be talked to. Of course, there is the easier method of letting them go but on the flip side, if the case is that the individual in question isn't aware about this stagnation/dip, they need to be informed - it could help in bringing them back on track of ascendancy. Which one of these ways to go, is a discussion for another day.
How do we do it?
There are many widely accepted practices in assessing a developer's productivity. But sadly, all of them have their own pitfalls. Let's look at a few.
Lines of Code/day: The easiest, yet the most flawed metric. Thanks to the fact that computing at its core is nothing but mathematics, a computing problem can be solved in a lot more than one correct way. Code that's written by a developer to solve a problem or meet a requirement, is a function of multiple factors including but not limited to the way (s)he approaches it, as well as their personal coding practices. Without going into specifics or jargon, Person A may code a solution in 50 lines while Person B might get there in 20. Come to the end of day evaluation, Person A has written 50 lines of code meaning a greater throughput but Person B seems to have gotten there in 20 lines, seemingly signifying efficiency. But B might not have accounted for some edge-case eventuality that A accounted for, tipping the scale of efficiency back in favour of A. Evidently, none of these represents a concise judgement of A or B's productivity.
Commits/day: Since version control is an integral part of the Software/Application development ecosystem, tracking the number of commits made by an individual in a day is a piece of cake. The problem here is that this gain is no telltale marker of an individual's productivity. While the apparent throughput of a person making greater number of commits on a given day is higher, there could be an individual who made a lesser number of commits but solved a more significant problem or met a larger requirement. Conclusion? This is no good metric either.
Tickets resolved/time: Development isn't always about solving new problems or meeting new requirements. Sometimes, it's about tidying up after someone else's mess; i.e. resolving a bug. This is definitely a better metric than those we have already seen. Every developer would agree that they aren't particularly fond of having to dive in and out, and tie up loose ends of code written by somebody else. The catch here is that the cause of some bugs are downright obvious while that isn't the case for others. There is an urban legend of an engineer who was called in to examine and fix an issue on a boat that many others weren't able to fix. He took a look around, tightened a screw and the issue that had stumped everyone was resolved. The engineer demanded a hefty fee for the job, reasoning that while the work seemed to involve nothing more than tightening a screw, only he managed to figure out that this was the work that was needed. Similarly, sometimes fixing a bug might boil down to a couple of lines of code but finding the cause of the bug is what makes the developer's work special - just that this isn't a generalisable case either.
Features developed/time: Did I give the impression that developing a new feature is simpler than fixing a bug in someone else's code? Pardon me, because it is not. A feature can be something as small simple UI updates like updating some colours, fonts, etc., as well as big ones like developing a new capability for your product. One might argue then that the size of the feature in question is a good metric for assessing the developer but again, it need not be. While most of the code for a new feature, particularly a big one, is written from scratch, serious consideration is how it ties into the existing codebase, as well as how much it accounts for scalability. More often than not, if the feature is an entirely new one that has only trivial tie-ins with the existing codebase, development tends to be easy. But there are cases when the new feature might tie directly into existing features, meaning that its development involves ensuring the feature not just works smoothly and as expected by itself, but also does not end up breaking things that re already in place.
Does that mean developers' productivity can't be quantified?
In the strictest sense, in a single word, NO. Assessing a developer's productivity qualitatively might be a more fruitful venture than trying to make a quantitative assessment. That is not to say that it cannot be done at all. It could be, perhaps using a weighted scoring system taking all of the above metrics as well as some others into account, factoring in behavioural aspects as well. Then again, it depends on where it is done and who does it. A product leader cannot and should not access a developer the way a managerial leader does and vice versa. Neither should the approach be the same in a product-based ecosystem as in a service-based ecosystem. And the methods should be different when the organisation is a state of small employee size, in comparison to an MNC.
It is curious that individuals who earn their bread and butter by scripting algorithms of one form or the other are at the receiving end of pitfalls caused by the lack of a good algorithm to assess their productivity.
Top comments (0)