Saturday, April 16, 2011

Thoughts on Management and Computing

Recently , I have been dealing with multitude of both the above topics. I realized midway through , how management concepts could be applied to Computing and how computing concepts could be applied to management.

Management Network

Lets start of with how management concepts could be applied to Computing. One of the strategies, when you debut a product is to customize the product according to demographics and region in which your launching the product. Consider the Food market , whenever somebody launches  a new food item in America, the emphasis is to be big . Whether its the Cola’s , Beer , Burgers or the Cars (Hummers) Americans like it big , its one market where Size does matter. Now consider the Asian market , the individual purchasing power is not as big as has in the west . So you need to make the your products smaller and affordable to tap into the market. An excellent example of this is , the shampoo sachet. In the west you could sell a Bottle, but in Asia the number of units of 2 Rs  sachets will outsell the bottles , people will not buy an Bottle of shampoo on a regular basis . Going by the same example you have mini cola’s for 10 Rs for drinks , the world cheapest car nano . The nano  may not be your a typical car in the west , yet it reflects a scaled down version of a car made affordable for the rising middle class. The important lesson in business not to view a large population with low purchasing power as an liability , but rather as an market  to whom you could sell your products scaling down on features and size to make it affordable. Now where does concept come in Computing . In fact its one of the tenets of the Cloud computing i.e, Rapid Elasticity. The ability to rapidly scale in and scale out the resources according to the demands of the end user.  This could be server resources which are increased rapidly during live streaming of an cricket match for website and scaled back down after the match is over. It makes no sense to buy all that server capacity  since the sports event is going to be temporary affair , rather renting out the server makes sense. So the Elasticity that offers flexibility to user based on his needs is no different from the  Business strategy that varies your product scale and features based on demographics and purchasing power of the market your selling to.

Computing Network

Now lets look at the reverse of taking a computing concept and applying to management. Most products in software are organized into modules and  developers work on their respective modules . Rarely does an developer take care of more than one module. You cant expect an User Interface(UI) engineer to solve bugs in the Backend or Database provider. The task we were facing was to create an start up  kind of an environment , where everybody works on everything ( at least most of the things ) . Mind you the product here is not something being developed from scratch . With couple of million lines of code spreading across four languages already in existence , It was mammoth ; there were isolated pockets of knowledge for each of the modules UI, Server , Cache and Back end. The challenge before the product management team was how do we merge them gracefully without wasting too much developer cycles so as to spread the knowledge.

To put it in different way the above problem is no different from what routers face in a large network , when they are plugged in new . The problem of learning the network , finding the shortest path to deliver the data to the destination , in other words how do we train developers in a module in the shortest duration. Each developer has to learn N-1 modules if there are N modules in the project. Lets try optimizing the solution. A developer working in Cache will some know how of Backend  and Server work since they are adjacent modules. So learning Backend and Cache will be less costly compared to learning UI . Hence break the Cache module guys into two equal halves and have them work with Backend and Server . There will be knowledge transfer to and fro from  Backend <---->Cache<-----> Server. Keep this going for one release , in the next release swap the Cache guys who worked with Server to Backend and Vice versa. Take this to other modules that are at the top and bottom of the stack. This is akin to Router  Packet forwarding table transfer in the  network to its immediate neighboring routers i.e, the hop count is one. The neighboring routers transfer its knowledge of network to its neighbors. Of course the router makes sure , it doesn't transfer the same message back to its receiver resulting in infinite loop. Finally depending on the number of modules you would have achieved , an optimal state where each developer knows most of the modules with the least amount of their cycles.  I guess this what you call reinventing the wheel when it comes to concepts.


Post a Comment