Measuring Productivity In Software Development Teams

Most software development companies measure productivity of teams and individuals. Those measurements are then used to rate the individual or group performance. Numbers are so nice, cozy and familiar. They make things simpler; and if someone’s productivity can be objectively rated with numbers, lucky is this person and lucky are the managers of this person. This person is lucky because the clarity of numbers backs the clarity of expectations, and if someone knows that they may get a raise if they hit a certain number of whatever, that’s great. Managers are lucky because they are spared the need of figuring out how the heck to rate people, so they can be given or refused a raise, or a promotion, or a reward.  However, in some cases mapping the actual value of an individual’s productivity and contribution to numbers might be challenging, if not at all unattainable.

Let’s look into the reasons why individual productivity is measured by counting things. This habit can be traced back to material production, or to any activity to product tangible things. If a farmer picks 100 vs. 50 cabbage heads per day, just an abstract example, this is surely good. One can not let a cabbage that is ready to be harvested sit for too long out in the field; it may fall prey to some pests, etc. With cabbages it surely makes sense to move fast, if we’re concerned with harvesting solely.  By the same token, a baker who runs a bakery on a busy street is more productive if she bakes more croissants. The logic is flawless: more croissants, more customers served, more profit.

With this measurement model looking so clear and simple, it’s very tempting to copy-paste this practice of “more is better” to knowledge work. The non-material production. They used to measure productivity of developers by lines of source code produced per certain amount of time. I wonder if someone still uses this metric. One smart person has something to say about it.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Other equally poor attempts to measure productivity include: count of bugs discovered by a QA (what if this person tests the heck out of a feature, making sure it’s clean, and finds no bugs?); the count of words in a written piece, or the count of graphic icons designed per day. These are abstract examples, and, thank God, it looks like most of the software development companies moved away from those naive metrics. The less is more adage is grasped better now, when we seem to live in the age of super-abundance of everything (which doesn’t save us from the chronic shortage of value).

That’s the word. Value. How much shippable, valuable, finished work has this person done? Working many hours is far from being equal to super productivity and, after a certain point, indicates inefficiency. What I call “productive” is when one uses time in the office wisely, rather than works around the clock. Then, which contribution is this person making to the group? What does he or she do to improve the workflow, or to keep the integrity of the team? Naturally, being a group contributor means that this person is biting some bits off of their individual contribution. What if this person contributes at a larger scope, beyond their core skill? Then, how to factor in the subtracted individual performance when measuring productivity?

With these intricate nuances, I wonder if someone is ever able to quantify them and use it as a numerical measure of productivity. Surely, the kingdom of tests and grades has its doors always open, as it attends to the needs of busy managers looking for fast and clear ways to rate a person’s performance. But, as often is the case, the flip side of fast is slow. Individuals concerned with the team’s success are the keepers, and if a numerical grade fails to code the value of this person correctly, they might be demotivated. We all are human, and managers are human as well (in case someone ever doubted that). They want to rate the performance of teams and individuals faster, especially if a company is large. Better safe than sorry, stakeholders better make sure they can trust the scoring methods. Otherwise, it would make more sense to stick to the old-school ways: observe people, what they do, and see if this brings value to the company. We know that it sometimes takes years for judges to be ready with their rulings. It might take what appears to be an eternity for a snail to figure out what’s inside this bubble. A rainbow or gas stains? But the time spent on deciding is well worth it.

Additional Resources