Winners don’t take all, or improve the averages
Source | LinkedIn : By Ramarao Kanneganti
Let me ask a question: name one south Korean computer science professor that is big all over the world? Or, even manager? Quick. I could not. On the other hand, name some Indian scientists or leaders. You can name several. But, name on Indian company that is world class in innovation? None come to mind as readily as Samsung, a South Korean company.
The point is this: in India, we optimized the systems for producing small number of excellent winners. In South Korea, (and most Scandinavian countries, for that matter) they optimized to improve the average people. In the book “No full stop in India”, Mark Tully writes about this phenomenon: even the successful Indian industries are geared towards single heroes, as opposed to large teams. India is the land of artisan that work by themselves. It is common to see a blacksmith in the village working all by himself.
The software industry in India may have started out by celebrating the individual heroes, but over the years, come to value teamwork. Most of the people who joined these companies are college grads that had limited exposure to programming. The success of these companies to bring them together and create a team and make them specialize in some computer tool, or programming paradigm of the times.
For instance, when SAP was vogue, they trained people on SAP. When Java was popular, suddenly you have lot of J2EE programmers. Now you see lot of places training people on DevOps, or even machine learning. It is an adaptive market.
In the end, what these companies aspired to do is to industrialize the development. They take the moniker “assembly line development” seriously. These developers know their tools well; they understand the process of getting the requirements and translating into code; they understand the abstractions they operate on — that is, somebody already decided on the entire stack, designed the framework, and handed out the module names for these people to code.
As enterprise developers, they are cocooned from some aspects of development. They do not think about where the programs are run. That is somebody else’s worry. They do not think about operations. Again, somebody else should take care of that. They do not do integration testing, leaving it to the testing group. They don’t do performance testing or DR testing either.
They do not have freedom to use what they want to either. They cannot use a labor saving library, because of the complexity of managing a new piece. They cannot choose the database for their solution — they are provisioned on the ubiquitous relational database with JDBC or ODBC connectivity. In general, enterprises are not a friendly place for open source, often with a good reason.