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](http://www.betterworldbooks.com/No-Full-Stops-in- India-id-9780140104806.aspx)”, 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.

In the end, they became like a glorified assembly line worker, in a non-fully automated assembly line; and that too in a work where creativity is often required.

Modern application developers are different. They operate on full stack. They experiment and come up with creative designs.

On the first blush, it seems problematic. Isn’t it inefficient? Didn’t economics teach us specialization improves productivity? Isn’t the whole innovation of industrial age is towards specialization?

There are reasons why it is not. Here are some:

1. Firstly, the current state of modern development is not suitable industrialization. The tools are changing constantly. The platforms are changing too. Any attempts at industrialization leads to suboptimal solution. In fact, that is where the Indian industry is stuck -- a suboptimal solution from ages ago.

2. Secondly, the tools that the modern developers use automate large number of tasks. The modern tools make the modern developers short circuit on lot of the tasks that only exist in the enterprise world. For example, the overhead associated with release cycles? Gone. Or, even the requirement delays? Gone.

3. Thirdly, the modern development offers a way to optimize the whole process, as opposed to individual parts of the process. For example, consider deployment engineering. Typically, it is done by different team that has no input into development. Without cross-team collaboration, there is no way we can optimize the processes. With full stack development, the small teams understand each other well. Better yet, the same team may be involved in rolling it out on the platforms designed by other teams.

Of course, there are others too, but in my opinion, the modern stack development works despite the broad based knowledge it requires of its practitioners.

What should companies do?

Companies see this phenomenon and interpret it differently.

They see that startups, silicon valley developers create applications differently. They see those people be more productive and more agile. They end up believing in the myth of super programmer. They think that they can get these super programmers to impress the customers. They think they can get these programmers to change the whole organization.

Lot of companies -- I do not mean merely Indian companies, but the non-valley, non-hi-tech companies -- are turning to these kind of developers. They get these people on the payroll hoping to transform the organization. But, these imported super stars or full stack developers do not understand how to change the organizations. They worked in an environment that made them productive. They cannot create such an environment in the new organization. They do not understand how to bring such a change to the new organization.

To solve this problem, companies came up with different strategies: they try bi-model IT (one part staffed with modern technologists and the other with traditional enterprise developers). They talk about pace layered architecture, where some systems are always built with modern technologies.

Yet, none of them work without creating a change beyond a few hires. They need to create a scalable model to create such developers.

My advice to the Indian companies is not to fall for such traps as hiring a few super programmers. Instead, they should increase the averages, like I said in the beginning.

What does it mean? They should focus on creating a new kind of environment, starting with the way they organize the teams. We cannot have multilayered system, where managers are there only to direct others to do their work. Like the [HBR article](https://hbr.org/2016/12/if-your-boss-could-do-your-job- youre-more-likely-to-be-happy-at-work) said, the manager should be able to do the job of his reportee. That should cut down on the layers a bit, I would think.

They should focus on creating a collaborative structure, that is beyond command and control. It should be unstructured; it should be context aware; it should be ad hoc; it should promote creativity and teamwork.

They should create a new training regime. Do not teach what is there on the internet. Let them learn it by themselves. I find the following ways work well, based my experience with one of my startups:

1. Set expectations: The old saying is practice makes perfect. No, it does not. Practice makes permanent. Learn to do it wrong, and you will do it wrong forever (like my typing). Instead, establish the best practices upfront.
2. Make them learn on the internet by practicing on the open source: Have them contribute to the open source. It can be documentation; it can be testing, porting or, a minor feature. That teaches them the basics are distributed programming.
3. Make them practice with the real problems they face in the world: Instead of starting a problem from the beginning, have them take a large problem and solve a bit of it. It makes them read and understand the code. If we choose the right problem and right solution, they will learn from the masters.
4. Let them focus on basic tools: We are enamored with large tools. We see if people know how to use a large system, say, Hybris commerce server, but not how DNS works. Lack of knowledge of the basics will hinder them where they are asked to fill the gaps in the state of the art platform.
5. Create a checklist before they can join a program: This list can validate if they know the best practices. Let them be opinionated. Let them learn to defend their positions. As long as they understand all the basics, they can contribute to the project.

In the end, a company that can transform its workforce to improve the average will do wonders. Superstars are for startups. Enterprises still need their large workforce until AI can write the programs based on what we talk to it. That will happen someday, thanks to the super programmers. Until then, heed my words!