Why do Indian websites suck so badly compared to American websites? Not just websites – it is rare to find a software targeted at Indian users that do not suck.
When a country is famous for its exports of “X”, you’d expect that the place to visit to pick up the best and cheapest samples of X is that country. Unfortunately, whether or not you are right in your expectation depends on the nature of X. If X is an agricultural commodity, you may be wrong, because the best examples of X might get exported, leaving behind export-reject stuff. If X is a manufactured product, you’d probably be right, because there is generally less variation in manufactured products than in products from the farm. Any improvement in quality can be quicky applied across the board, resulting in benefits for all users, including domestic ones.
IT is of course a service. Services vary quite a bit in quality. In this regard, it is more like an agricultural commodity than like a manufactured product. It is interesting to dig a bit into why IT products targeted at India turn out to be of poor quality.
One problem is the “Bangalore Bug“. Indian clients tend to offer low margins, so when they hire IT companies, they tend not to be the best in India. Even when the best are hired, it usually happens that the domestic market is a low priority for them. Indian clients tend to think that hiring a small Indian IT shop for whom you are the largest and most important client will give you better service, but it is actually difficult to say. The small IT shops tend to have poorly qualified programmers, all of whom are looking to get some experience and move to a better job where they have better “onsite opportunities”. The larger ones tend to have better qualified programmers on average, but you will not get the average programmer – you are more likely to get the guys who are on the bench, and they tend to be constantly on the look out to move to a project that will give them onsite opportunities. (They don’t necessarily want to move onsite – a career that will enable them to deal with American clients over the phone is still better for them than one where they have to deal with Indian clients.)
You’d expect that advances in Software engineering like ISO 9001 and CMM that Indian companies have adopted will reduce this problem. After all, the whole point of implementing Quality processes is to ensure consistency and nudge IT applications in the general direction of a manufactured product. But one of the ill-kept secrets of Indian IT companies is that they still depend too much on their clients to drive quality for testing, and for general goverance. What this means is that if the client asks them to follow CMM or something, they do it – the best companies do it sincerely and quite well. But if the client does not, even the best IT companies will not follow those processes as a matter of course. In addition, some crucial pieces of the puzzle – like User Interface design, Business Analysis and Process Mapping still tend to be driven by the client.
Now, application development is a two-way street. If clients do not communicate requirements clearly, do not read specifications developed by their vendors, change things at the last minute and do not do user acceptance testing once the software is developed, there is no point blaming the vendor. Clients in general are notorious for doing these things, but Indian clients are worse than average in this regard. One reason for this is that the client’s IT department suffers much more from the Bangalore bug than the software companies do. In the US, a job in the IT department is a respectable career. In India, the talent tends to migrate to software companies or to IT departments abroad. More importantly, American companies tend to have a lot of experience managing software applications since at least the 60s. In India, really senior folks who understand IT and can make a case for an IT strategy are often hard to find. All these things mean that clients tend to have a lackadaisical attitude to application development, underestimate the costs involved, expect too much from their vendors and underestimate the extent to which their own involvement would be required. The typical mistake is to budget for a one-shot development effort and not for maintenance, bug fixes or for future enhancements. Often, a software project for an Indian company is underfunded, badly speced out, does not have clear exit criteria, results in a badly developed product and ends in acrimony. When it is deployed and the bugs and user feedback come out, there is no budget and no enthusiasm for using it to improve the application.
The final and most important reason, of course is that Indian clients do not care too much about quality. If a software bug leads to user annoyance and support calls, American companies fix it. An Indian company will probably not even measure the extent of the problem, and even if they measure it, I suspect that they will find it cheaper to throw money at a manual workaround than pay a software developer to fix it. This, I suspect, is both because labour is cheaper in India and also because the software developed is so badly snafued.
Obviously, not all of this is true of all companies, and much of this is likely to have been truer in the past than it is now – I suspect that Indian companies have become more aware of the importance of IT, and the all-round rise in salaries means that a career in the IT department of an Indian company is much more fulfilling now than it was a few years back. But I also suspect that some things have not changed – software companies still don’t care too much about Indian clients, and the clients still do not caree too much for their users. What do you folks think?