Rohan Murty wants to measure programmers' productivity

Many of us associate the concept of measured productivity with the blue-collar world, with things like automotive assembly lines and steel mills. For the rest of the world, encompassing lawyers, managers, doctors, and, increasingly, journalists, paychecks often hinge on many other things: Revenue and profit increases, stock price appreciation (and correspondingly, market caps), client additions, a death rate that doesn't elicit unwelcome attention, and page hits. If you're a trader, the equation between money made and lost on a daily basis is your metric of productivity, even if you were losing money for most of the day and made it up, and more, on your last trade of the day. How efficient you are per unit of time becomes largely irrelevant.

Software programmers have always fallen into this nebulous category -- stereotyped as creative geniuses who write code and cook up fabulous things like the a browser for the world wide web, or code that can operate a robotic arm for use in neurosurgery operating rooms. The very words Pascal, C++, Java, and Python conjure up images of brilliant geeks who slave over a computer for days and produce magic at the end of it. There's no way of quantifying the immense and immeasurable value that they seem to bring to almost every aspect of our everyday world that is governed by software in ATMs, thermostats, and on websites delivering your latest hiking boots.

Or is there? If you listen to Rohan Murty, 32, son of Infosys co-founder Narayana Murthy, you will hear that not only is this not true, but also that the whole field is getting massively commoditised sooner than you can say Cobol. It is, in fact, already on the cusp of industrialization, especially in the areas of programming, testing, maintenance, infrastructure management, and some aspects of business process management. In other words, these functions have become the assembly line of the software field, far removed from the two guys in a garage writing code that is almost always destined (in tech mythology, at least) to make them a few billion dollars.

His father may be the poster child for the Indian software services sector, but Rohan Murty is no tech lightweight, either, at least as far as his academic pursuits are concerned (his entrepreneurial chops are yet to be proven). With an undergraduate degree in computer science from Cornell, Rohan completed his PhD in the same subject from Harvard, and was also a Computing Innovations Fellow from no less a temple of science than the Massachusetts Institute of Technology. His interests apparently span networked systems, embedded computing, and distributed computing systems.

Recently, he spent one tumultuous year helping his father (in the role of an executive assistant) attempt to resuscitate the moribund Infosys before the elder Murthy brought in SAP's Vishal Sikka to do so. Both Murt(h)ys attracted significant flak for going against the decades-long credo that the co-founders of the firm sculpted out when launching their baby that no progeny would take any kind of management position within the firm.

Rohan must have been one relieved camper to jettison what was a very hot potato and go on to to immerse himself in his true love -- namely, issues involving artificial intelligence and automation -- by founding an innovation laboratory in Boston solely through the Murthy wealth. The laboratory will immerse itself in what Rohan thinks is the next big challenge, or urgent imperative, in the software industry: How to measure productivity.

Any software worker (that seems to increasingly be the correct term to use) who fits into the above-mentioned categories, Murty said, should get used to the idea that much of the profession is becoming very much like the auto industry, where the industrial revolution and an assembly line allowed for scale, differentiation, and quality -- all of which are prime challenges in the industry today. The reason you are able to drive a quality car with air bags and anti-lock brakes relatively cheaply is because of massive strides made in figuring out how productive tasks, processes, and workers were and are in areas of cost and quality control, all of which are things that the software industry fails to do today.

"How does one measure how much output a software engineer produces? How does one scientifically determine how many software engineers one needs to solve a problem? How, then, does one pick people to form a team to solve a given problem?" Murty asked in a Business Standard Newspaper Q&A.

It is a fact that today, people don't measure value given to clients, largely because of the ritualistic price cuts awarded at the end of a negotiation that keeps a customer happy. But that day is almost over -- just look at earnings estimates for major Indian players. The bad news is that this new era in software services, sans any radical breakthrough, will undoubtedly be more exacting on margins.

Ultimately, the task of differentiating yourself from the next firm becomes a monumental challenge, even if you attach the buzzwords of big data and analytics to your offerings.

Lovers of science fiction may then infer that this word seems to be inexorably heading towards an Orwellian dystopia, with the "suits" straining to rigorously monitor their programmers and squeeze every drop of sweat from them.

Murty said that this doesn't have to be the way you look at it. "It is impossible to expect every individual to operate at the top end of the productivity curve. There will always exist a variation of productivities in any team. However, we took steps to improve the productivity of individuals by targeting specific training, enhancing the process via which work was distributed to members of the team, or even construct an all-star team (much like the NBA) consisting of high-productivity individuals across the organisation to solve specific problems for urgent needs for clients."

It is a complicated task at hand. As Murty put it in the Q&A, computing how productive Engineer 1 who is writing code in Python versus Engineer 2 who is doing so in Java could be brain-twisting stuff. But this is a challenge that he firmly believes is necessary, and he is willing to take it on in his new productivity-measuring lab.

Whether IT managers and their herd take to it, and whether it will cause a conflagration, is an entirely different matter.