The Fastest is doing it right
Measuring productivity in programming is a thorny.
What's that?
Productivity is the amount of work done in a unit of time, and time is money.
The longer a person works, the more pay s/he gets. The longer a project runs, the costlier it becomes.
From a buyer perspective, you want your order fulfilled as quickly as possible, the best goods and/or services, and at the lowest price point. As a provider, you want your workforce at its full capacity, delivering more, not less, at the highest quality possible, and of course scale to enriching your treasury further.
That's economics, and how the market works.
However, the moment things don't work on the provider side, or simply when greater profit margin pressure kicks in, you may decide to come up with productivity measurements for software development. OK, but let's take note of this: Things may go south real fast. Not immediately visible, but eventually it will be.
In case programming isn't something you've done for at least a few years at a professional level, let's get the basic straights, it's universal.
A computing machine is a piece of hardware that executes instructions, usually stores data, may be local or somewhere remote, aka in the cloud. It has input and output streams. All these properties can go so fast, it's possible a single computer could outperform faster than the entire world population. Could. And, for certain things, not all things, at least not yet. More importantly, the hardware along with the software layer on top of it does nothing on its own. Its prowess is entirely dependent on the programs authored by the programmer.
Some programs written with common decency these days can process billions of records in a matter of minutes, or even seconds. With high level of accuracy and reproducibility. However, it does require a coder to grasp much important software engineering concepts, supported by some infrastructure to edit, compile, build, and distribute the set of instructions for execution on that very machine. Potential issues with networking, persistence, running out of memory under certain scenarios, or mishandled error can make all the magic vanish and be left with an unresponsive colorless boring box. All it may take is a reboot of the program to get back on the horse. Or it could take a few hours to figure out why the program keeps chocking on this nearly identical sets of data getting consumed. Or take days, weeks. Maybe the program will never ever work again. Machines are all capable, but aren't made exactly equal. Architecture matters, a program that runs on an Intel x64 CPU has little to chance to work as it is on an ARM64 chip. Programmers? They can adapt, usually. In any case, significant amounts of time is spent learning prior to write that program, and for this one it likely took designing, coding, testing, debugging, and iterating until the program can correctly execute.
In software development, far more than at some factory line, productivity is not linear.
Junior to mid-level developers often commit code every single day, yet fail to deliver a working solution at the end of a cycle, long or short, same. The more experienced coders are often seen as passing days without pumping any code. Even to their own surprise, at the end of the sprint, they deliver something that may actually work. They tend to knowingly diverge from the initial requirements, usually to skim what's causing more problems than they solve, and to fill a few important to consider gaps here and there.
What do senior developers do
In reality, not much. As I said, they can spend days without touching their code editor. If they do, it's to scratch some snippets to verify certain theoretical assumptions, they may develop an entire POC to see how an entire system may behave then throw it in the trash. Or would play with some library, seemingly having nothing to do with the urgently needed feature the team is tasked to produce.
They may look over at the requirements, again. Then go for an hour walk to appease their urge to IM that business analyst with words better not sent, about requirements that were long ago settled and handed over across multiple development teams that by now have started development. Perhaps even their components already. They perhaps get dragged into some peer reviews. Or trapped into trying to explain that algorithmic mystery question someone posted in the main channel.
I meant real seniors developers, just in case. If that isn't a senior mind, then it's exactly the same, except that he would broadcast to many colleagues what he's been up to, in the hope to be told he is the real deal.
All that and more, unexpected activities senior devs gets into, don't necessarily take the majority of their time nor much of their brain power. Sometimes they do. But here is the kind of work that occupies at least their neurons throughout most days, in particular when they appear mind wandering during a call, a real obsession that even comes bothering them while asleep.
|:--:|
|
They've already tried to apply the theory and so infrequently saw it turning into nice reality, they accepted long ago that reality is a beast - think how a juvenile feral cat, well cornered by a Mediterranean team of former rodeo, or bullfighters, is trapped in a small alley, and how that cat would defy gravity as the crew blink their eyes synchronously, then run faster than a gazelle and disappear through a straight concrete wall which after inspection got no hole bigger than a half a mouse and stands 5 meters high. They figured the better approach to take is to strike the right balance early on. Every problem is unique, the context changes along the way, getting the balance is an important decision to make. For everyone's sanity down the road, at least theirs.
On measuring productivity
Some businesses still measure productivity using numbers of use cases, classes/files, functions, even lines of code counts. Another supposedly effective stick is the number of pull requests along with commits coming in overtime. Service oriented companies rather look over the number of tickets closed and resolution times, NPS scores, stuff like that, and try to figure out the best individuals, and who needs some support for adjustments.
At some point though, these measurements become the props of a theatre act. Formalising the measurement process? The stage actors tap dance on it. Overall, moral goes down, the undiserable aspects of competition kick in. Comments like this is comparing apples with oranges from those who don't know how to tap dance or refuse to transition into a career in communication knowing fullwell the next move will then be into Politics. It isn't comparing apples with oranges, it's more often comparing a bag of fruits with a spaceship. Losing grip with value on top of that. Misunderstanding value surelyh doesn't help make any comparison anywhere near valid, at this point all that matters is who's right. Not what is right.
This sort of measurement is not only overhead. Resources constantly invested into this mascarade tend to snowballs. It's social, and in a way determinant to move the neddles. Nobody ever measure its cost of course, that's one thing that is immunte to questionning in term of actual cost vs benefits. It then results in more and more stress on team members, especially those who would be most productive. They now have two jobs. One they hate, one they have barely any time left to do right. Overall work dissatisfaction takes ground. Instead, the developers become less productive. Can it get more counter productive than that?
Yes it can. I won't discuss the other patterns many experienced engineers have deeemed nepharious to throughput, there are plenty of stories out there better writen than this piece, more sensatinal but reality isn't too far off. Instead let's summarise key components of engineering productivity.
Productivity in this field is achieved by doing the right thing. That's it. Even that is easier said than done, leaving alone tracking and measurement, some much needed prerequisites:
- Coders grasps computer science and engineering concepts
- No significant nor frequent interruptions, that is crutial during those revelation moments when solution crystalises in the coder's mind
- Calm, an environment prompt to see the forest rather than just trees
Experience comes with time, no known ways around it, the last two factors boosts the learning process. Want more productivity? Focus on those prerequisites and help tend towards maximising those. The rest shall come naturally, and, again, experience takes time.
Want to measure throughput anyway? Can't believe the team is only capable of delivering so little? Suspicions of slacking or lack of synergy?
I would say if you are thinking in those terms then track what you have been doing with regards to enabling the team. Question your own beliefs and ask people that have solid experience whether those actions were useful, insufficient, or potentially counter-productive. If nothing of note to adjust from your side, then question how the organisation recognizes and reward great contributions. It isn't just about compensation and benefits, but it plays a part. You may not have a say in it, but you do.
Measurement of productivity ends up like Schrödinger’s cat in this domain. It does make sense though, to think of productivity at the macro level, the team's overall throughput, how it trends. Keeping along a measure of how that team is maturing even if results wise it seems nothing like reMarkable is coming out yet. Without loosing sight of quality, itself measured by looking at the target audience's satisfaction. No audience yet? Try to use the system yourself. Even early on, some pieces should be ready. If not, then try harder.
Finally, don't consider mimicking Amazon and its factory-era management style. Bezos can pull this off, not many other leaders can. Even then, this culture comes with a lot of churn, attrition wounds, risks in the longer run, and questionable ethics may slip through the cracks due to some misunderstandings.
if you can't reasonably do anything positive about a thing, better let it be. Someone else may, and, if all you may have is either a bag of fruits, or some spaceship looking thingy, you better favor the bag of fruits. No matter how hard or well people convince you otherwise.