Comments (0)

By Krishna, August 31, 2007

Ouch!

I landed on this Wikipedia article on Indian English which had some of the common mistakes in Indian English grammar. After decades of speaking and writing English, it is funny how some of the incorrect English habits (or “grammar tweaks”, as they call it) persists in my speaking and writing. Reading an article is the textual equivalent of seeing a parody of oneself.

In India, proper British English is taught in Indian schools and colleges. And many educational institutions are English-medium. Unfortunately, there is not much opportunity available for children to practice English outside the classroom. Until the advent of cable TV, there was very little English they could listen to, either. Things are changing nowadays, though, with increased globalization, but despite that, the primary spoken language is the local language.

Since I grew up in Kuwait, I didn’t face such issues. There, the situation was that the Indian children came from different states in India and spoke different languages. So the only way we could communicate in or outside the school was talk in English. The problem was that there were no native English speakers, such as from England or the United States. So we never dropped our Indian accents.

When I went back to India, I sub-consciously picked up some of the usages of Indian English grammar through friends and teachers. And then while working in Bangalore and Chennai and later managing offshore teams, I got exposed to different variants of Indian English. Here, the thing to remember is that you must use those variants instead of using perfect English; otherwise chances are that you will be misunderstood. For example, if you don’t use phrases like “Only if you do this…“, “This is nothing but…“, people may not understand the importance of what you really want them to do or understand.

One of the funniest usages I have encountered is the confusion between “hope” and “think” for some people. When I come back after a sick day, my offshore team members would ask me, “What happened yesterday? We hope you were ill. We think you will get better.” The first time, this really stunned me. Later, I got used to it and I tried to eliminate my use of those words to avoid confusing them.

The Indian accent is really a big drag when you come to the United States for the first time. I remember going to a retailer once and asking an associate, “Where can I get fluorescent bulbs?” She looked confused and asked, “You want a Barbie doll?“ She did seem odd, so I am not entirely sure if it was my accent that led to this misunderstanding. I also had enormous trouble ordering “Vanilla Chai” from Dunkin’ Donuts. Don’t ask me why.

There is this time-honored practice of Americans speaking English slowly and loudly to foreigners who don’t understand English. The reality is that Indians here are usually reduced to doing exactly that. Our normal speech is way too fast that most Americans have a tough time understanding us. So we have to slow down, use a louder voice and distinctly pronounce each word. After some time, you get used to the new style.

One of the companies we worked with had another partnership with a Russian outsourcing company. The developers, who were based in Moscow, were very smart people who wrote perfect English, but they would never come on the telephone. They would only communicate through email or chat because they found that phone calls didn’t work for them with their accents. This is true – sometimes if a person has a very thick accent, you need to do lip reading in addition to using your ears to understand them. For example,

“Djya sine zcon tract? aaru fyn vid chaynj two kloz phiph teen on zcon tract phen altyes.”
“So you are telling me you didn’t make any changes to clause 15 on contract penalties. Great! I will sign and have this faxed over right away.”

Moral: Don’t do this stuff over the phone.

Once you have an accent, it is very tough to “let it go”. Very few people ever do, regardless of their origin (Europe, Asia or Africa). Sometimes the accent is cute to the natives, like these British nationals in the States (scroll to the 37th over), but other times, an accent is just an accent. It, therefore, comes a minor shock when you see an Asian (or Indian) person start speaking perfect American English. Then you realize that they are American citizens born here (with one or two immigrant parents) and have been speaking like that all their life.

As the world continues to integrate and you work with people of different nationalities, you will increasingly have to deal with language issues on your side as well as from other people. Such issues used to be rare, only faced by top managers who specialized in international management and kept flying around. Now, individual contributors too have to grapple with it sooner or later.

Are you ready?

Comments (2)

By Krishna, August 29, 2007

In the last couple of days, Phil Haack and Guy Kawasaki (separately) have written beautiful posts on subjects that I mentioned in my latest posts.

On validation, Phil writes “Don’t Be a Validation Nazi” to follow on his “… How to Validate an Email Address …” post. My article on the subject of unnecessary field validations here.

On hiring, Guy writes “How to Not Hire Someone Via Craigslist” explaining, among other things, how a more detailed job description can drive away job applicants. My article on hiring here.

The last few comments on the blog have been interesting, giving me some ideas for new articles. Alexey Linkov (who has a good blog on outsourcing) has suggested an article on best tips for hiring programmers. Bruce has remarked about how Agile methodology may require dedicated requirements personnel at all times, which lead me to an idea about writing about how to make Agile successful in an organization. I have added a new section on the right side that lists possible topics for the future.

If you look carefully at my links above, you will notice that I have finally bit the bullet and bought the www.thoughtclusters.com domain. My primary motivation was not having to change the title of this blog, supposing someone else buys the domain.  Google makes the buying process very easy through Blogger itself. It costs around $10 per year and you get Google Apps Standard Edition with it. Blogger also takes care not to break old links and forward them appropriately. Not bad.

Finally, I signed up for Bookswim. At around $20 per month, it could potentially save a lot of money on buying business and technology books. The site has been slow for the past week because of heavy traffic and has some hiccups with search. But they seem to be responsive in email communication and I already have my first set of books shipped to me. Overall, it seems like a good deal for customers.

Comments (3)

By Krishna, August 26, 2007

If you ask any manager about hiring, he or she would say, “I want to hire the best employees and my hiring process is streamlined to do that.” There is quite a lot of material, if you wish to read, about how to interview employment candidates to find the best one that meets your project or organizational needs. Typically, most managers seem fine with their hiring process. But what is really, practically going on? Let’s analyze this.

Let us say that you have an opening for a developer. You determine what level of experience and development skills a person should have. You write down a job description. You advertise the position. You get a few responses. You interview the candidates and then you select one. Here is what is happening to you at each step.

1. Under normal circumstances, at any particular instant, the majority of developers are not looking for a job. The best developers would likely have gravitated towards the companies best suited for them, because they have the capability to get into those organizations. And less skilled developers to organizations that match their needs.

   A developer may be looking for a job if their current employment situation has some drawbacks such as less compensation, unhappy work environment or lack of good opportunities. But this is balanced against the costs of leaving the job including relocation of residence, instability, adjustment to an unfamiliar work situation, etc. This means that even if the person is looking, they may not shift unless there is a significant difference in compensation or they are very disillusioned with their current job.

   Things change during times of economic (or industry) downturn and upturn. It is actually easier to find more developers during times of industry growth because salaries increase and people do not want to be left behind in “making hay while the sun shines”. During downturns, people would rather stay with the existing company if it is holding steady because shifting to an unknown company is riskier.

2. It is unlikely that most developers will even see your job opening. Unless someone is unemployed and actively searching for jobs, the chances of them seeing your job posting are low. You are also competing against many other companies for developers in all the usual job sites like Monster or Dice. You can try niche job sites, such as those running on some popular blogs, but there also you are competing for eyeballs.
3. Even if they see your job opening, they may decide not to apply. But this is something over which you have more control. What you need is to provide more information about yourself so that the applicant feels confident about your company, the work environment and career opportunities. Secondly, the more qualifications you put in the job opening, the more potential applications you lose.I have learnt the lesson the hard way. You sometimes write up a very accurate job description and necessary job qualifications. But the more detail you have, the more likely such a person exists only in fiction. You also end up scaring away good candidates who think that the job is more complicated than it seems. The problem is that if you generalize the job description too much, then you get too many unqualified candidates. Finding the right balance is frequently a trial-and-error exercise.
4. Suppose you receive applications. When you decide to filter them, you are primarily basing your decisions on the resumes. You may actually end up rejecting a few good candidates because their resume did not “look good”. A developer who is not good at presentation or marketing skills may be at a disadvantage in this filtering process.There are 2 schools of thought here. On one side, you could say that someone who does not pay attention to writing and presentation is probably not a good fit for your organization. On the other hand, many technically good people are poor in effective communication and presentation. Besides, most people do not spend every day polishing their resume. Usually, they start working on their resume only after they need a job and probably stop after the first draft to spend time looking for job openings.
5. Finally, you start interviewing. Let us side-step the issue of how you actually interview people because, to a great degree, how you interview people (phone interviews, written tests, whiteboard coding, group discussions, face-to-face technical interviews, etc.) is dependent on the needs of your team and your organization. The more your interview methods are in sync with your needs, the better people you will hire.But one problem with any interview process is how many people you actually interview. You would actually like to interview as many people as you can, but limitations on time and budget force you to restrict the number of interviewees. The second issue is that if you are doing interviews in series, each interview can bias the nature and result of your next interview. You may also decide to stop if you find a suitable candidate, which means that you are possibly forgoing a better candidate.
6. Finally, after all this hard work, you really don’t know anything about the person until you see them in operation with your team and producing results. Sometimes, incompatibility problems may become visible soon, if you are lucky. Sometimes, they may only materialize much later when you are more dependent on the person. Also, if you were very dependent on that person for your project needs, you may consciously or subconsciously ignore many warning signs until things come to a crisis situation.

The reason I outline all this is that many people do not have a clue how far they are away from a perfect hiring process. They think that hiring is like evaluating 10 software products and then selecting one of them for the next project. Here, out of millions of software developers, you are only looking at a fraction of a fraction. And if you belong to a small or mid-size company, then you don’t even have that.

It is, of course, not anyone’s fault. It is just the natural rules of the game. And I don’t see much anyone can do to significantly improve upon the percentages. Perhaps the most important lesson from all this is that hiring and getting someone that meets your needs perfectly is an incredible stroke of luck. Cherish such hires.

And don’t be surprised or upset if things don’t quite work out with a new employee. It is really impossible to get a perfect match with such a limited pool of selections and within such a short duration. There is always a possibility you made a mistake. Fortunately, most people are good at adapting and frequently learn how to fit in with the organization. And somehow it all works out.

Comments (7)

By Krishna, August 25, 2007

I was reading this interesting article from Haacked.com about email validation. The author Phil Haack illustrates how most email validations are really too strict because the RFC (Request for Comments) really had a much liberal interpretation of what characters an email address can have. Although in practice, most mainstream email services (like Yahoo! Mail and Gmail) do have certain email address conventions, there will be a few valid email addresses that do not get through.

Here are a couple of validations on other common fields that can be frustrating for people:

1. Phone numbers: Many novice developers instinctively go and put an all-digit validation or a masked edit (like “(111) 555-9999″) to the field. This is wrong for many reasons:
   1. You may have mnemonic phone numbers like 800-ASK-ABCD, which use alphabets.
   2. International phone numbers will require additional digits and characters.
   3. Phone extensions and special codes (#, *, etc.) for reaching people may not pass such validation.
   4. People may want to use their unique way of viewing phone numbers like, say, 111.555.9999.
2. Names: The most common interface for names is having 3 text boxes – two large ones for first name and last name respectively and a short one for the middle initial. And the validations are usually always alphabet-only. Again, the issues are:
   1. How do you represent a name like “Warnakulasuriya Patabendige Ushantha Joseph Chaminda Vaas“? OK, I am being a little extreme there, but many non-American-born people have more than 3 words in their names, including me.
   2. On the other hand, some people don’t have a middle initial. My wife (with only 2 words in her name) had a problem with the US Citizenship and Immigration Services (USCIS) website; fortunately, it was only a warning and not a complete block.
   3. Names can contain numbers and punctuation marks. Like “John Smith, Jr.”, “Daniel D’Souza”, “Mary Wilson-Smith”, “Jack Ford, III”, etc.
   4. European names can contain more than the normal ASCII set characters.

I am not saying that such user interfaces are dumb. Far from it, there are good reasons why people may want such an interface. In the case of the name fields, for example, administrators may want to search individually on first and last names, and the application must force the end user to specify them separately. Many people are more comfortable with reading a list of users with last names starting first, like “Smith, John” rather than “John Smith”.

Also, some applications do try to get around some of the issues by having separate fields for country codes and extensions, or even the three parts of the phone number itself. Such a function may be useful if you want to, say, show only people with a phone number in the United States or a regional area code. I can think of salespeople needing such functionality for cold calling purposes.

However, my point remains. Many times, developers add such functionality without any thought about the end user. Usually, they have seen some other similar user interface and think it is the right thing to do. I plead guilty to having done the same thing in the past.

Some questions that may help in determining whether the validation and user layout is indeed required:

1. Does it matter if the field contain junk data? For example, if a person enters “!@#$%^&*()” as a callback telephone number in a “Contact Me” form, he obviously does not want you to call him. So do you care? (Aside: Try doing a Google search on that phone number. LOL.)
2. Does the end user distinguish between the different parts of the data? For example, the extension as a separate field is really meaningless because users are not going to search on phone extension. Or are they?
3. Does the end user want to force the display of some fields in a certain way? If not, maybe you don’t need masked edit controls or separate fields.
4. There are other application-specific fields too, which you may want to investigate. What fields have validation they don’t need, including a check for mandatory values?

Finally a word of caution: I don’t intend to demean all validations. Obviously, many of them are important to maintain data integrity. So analyze your situation and application needs carefully.

Comments (3)

By Krishna, August 25, 2007

Kalpesh left a very valid comment on my last post on overcoming the inertia against writing requirements, where he said that this task can be better performed by someone “who understands domain of the customers & enough of technology”.

I fully agree with this comment as, from experience, I have seen dramatically improved results when a person is fully dedicated to the task of writing requirements and who is both knowledgeable in the technology used as well as the business domain. The reasons behind this are:

1. A person fully allocated to collecting and managing requirements has a much better feel for the integrity and completeness of the requirements. Since they are always thinking about the requirements, they can easily find and plug gaps in the analysis. When the person does this along with other tasks, they only do analysis when they are writing or gathering requirements, not at other times.
2. A requirements analyst fully focused on requirements can continue to develop skills and techniques that help in improving the quality of the documentation. There are many areas of improvement possible: The methods of gathering requirements, the writing and presentation skills, the ease of translation into code, etc.
3. A person knowledgeable in technology can help non-technical customers understand what is possible and what not. For example, I have seen many customers use their client/server environment experience to suggest certain web user interfaces. While new technologies like Ajax does allow you to create highly interactive interfaces, there are limits and costs to such user interface demands.
4. A person knowledgeable in the business domain is much better placed to understand user needs. However, I have found that most people are capable enough to gain a working understanding of the domain in a few weeks and it is also impossible to know everything because of changing regulations and business environments. But in short-term or critical projects, it is too risky to assign an analyst who is new to the business domain.

Unfortunately, for many organizations, departments and teams, it is not possible (for various reasons like cost, resource availability, etc.) to allocate such a suitably qualified person for requirements alone. Even in many successful software companies (product and service), I have found that the analyst usually doubles up doing a lot of other work such as design and acceptance testing, and sometimes even coding.

One reason for this is that requirements is usually an activity that has a distinct peak of activity (user interviews, documentation, etc.) followed by relatively low effort in maintaining the requirements artifacts. Even a highly detailed requirement needs several times the effort to convert into design, coding and testing. In the meantime, the requirements analyst will be relatively idle. And although they may be called in for clarifications, this would not be a frequent activity if they have done their job right.

In any case, if a team cannot afford a full-time requirements analyst, the developers in the team must take up the task of requirements collection and analysis. And that was my point in my previous article – many developers do not like doing that leading to innumerable problems in project schedules and project quality.

So if you are a project manager in this situation who finds that requirements management gets put on the back burner when compared to coding, you need to understand what exactly is going on. Unless you spend time to train people, remove their fear, allocate dedicated time for analysis and show them meaningful examples, the problem is not going away.

Comments (5)

By Krishna, August 23, 2007

Here is a fact of life: When given a development task, most developers directly jump into coding with the bare minimum of understanding or documenting the requirements. This happens despite the common knowledge that lack of proper requirements management can derail the project and result in an application that has little value for end users. But everybody keeps doing the opposite. In the past, I have been no exception, either.

Why do developers do this? One fallacy about lack of requirements documentation is the thinking that perhaps programmers do not know the value of requirements enough. Such an argument holds as much weight as saying that people don’t quit addictions like alcohol and smoking because they don’t know about the harm caused. People are intelligent enough to understand the benefits and costs of something, but it is very difficult for them to change what they are doing even with that knowledge.

So what are the possible causes?

1. Developers don’t know how: Many developers have no idea how to write a requirements document, let alone a good one. Many times, developers are asked to document the application they have already created. But they don’t know how to create a document directly from the end users. Sometimes, the developers are aware of the standard requirements template (like the IEEE template), but don’t have any experience in filling it out.This lack of knowledge creates several mental blocks. Without understanding what is involved, the developer feels that the task of collecting requirements will take a long time. He or she may feel incapable of handling the task. The software developer may not know where to begin. Also remember that it is not just documentation; it also involves activities such as customer interviews, system analysis and study of existing documentation.
2. Coding produces a solution, requirements doesn’t: When you code, you produce a tangible program that can be demonstrated to customers and end users. When you write requirements documents, all you get is a document and you still need to spend the effort on coding. Hence, there is a feeling that writing requirements “wastes time” that could have spent on coding. Plus, many programmers feel guilty when they go through periods of not coding. It feels like idle time.The reality is that requirements document save time in the long-term by avoiding misunderstandings and helping programmers code without spending time trying to figure out what the users may have wanted. Adding new project members can also be less painful because they can read through the documentation. But such considerations are not immediate enough and people go for instant gratification.
3. People cannot figure out a happy medium: One reason why many people hate requirements documentation is that they don’t know how to create documentation that is just sufficient for development needs. Sometimes they create too little, which is useless for practical development purposes. Such a document becomes shelf ware. At other times, people create too heavy documentation, which is very difficult to navigate or maintain, thus creating more resentment.There are 2 primary audiences for requirements documents – the customers (to validate) and the programmers (to code against). It is very difficult to satisfy both sides. If you make it detailed enough for programmers, customers don’t have the time or patience to validate the document. If you go in the opposite direction, you find programmers making unwanted assumptions. In short, creating a requirements document is very tough.

Education is not the solution. Providing examples and opportunities for developers is the better path. Here are some tips:

1. Lead by example: If you have never created a requirements document yourself, it is difficult to tell people what it entails. You should try creating requirements documents that suit your organization and the type of projects that you do. You can start with existing standard templates, but quickly customize them to your needs. Liberally use feedback from others in your organization. After all, they are the ones who are going to be using it regularly.
2. Give small assignments: Get people to be comfortable with writing requirements by giving them small analysis tasks before they start coding. Do not give tasks that go beyond more than a few hours. Also try to provide instant feedback when the write-up is provided to you so that the developer doesn’t feel he or she is losing time in completing the work. Remember that the first few times a developer does this, they are likely to make more mistakes and take a lot of time to get it right.
3. Facilitate and encourage analysis and design: Coding can be fun at times and you can perform cool tricks with various programming techniques. But much of coding is really cruise control. You know what you have to do and you just do it. And that is why people just dive into coding – the flow is more natural. Thinking is tougher. And hence, you need to actively force people to spend time on analysis and design so that they can get used to thinking and brainstorming. Once they get used to it, they may like it better than coding.
4. Avoid religion: CMMi and Agile have diametrically opposite views of documentation. Organizations may follow either and that is their prerogative. But requirements documentation should not be the slave of one particular school of thought. A requirements document is the lifeline for the development team. Follow what works. If it is less than or more than what your methodology specifies, so be it.

Comments (1)

By Krishna, August 16, 2007

A couple of weeks ago, we moved the TV from the living room to my study room. This has enormously reduced wasted time watching stupid stuff on TV. Otherwise the TV is on all the time. Half the time, you spend watching the advertisements. And the rest of the time – well, let us say that the advertisements are more entertaining.

In my view, TV is one of the most wasteful uses of one’s time, unless one is extremely picky about what one watches. The tendency is to keep it on even though there is nothing interesting. When you have more TV channels, you keep flipping the channels until you find something that you can just tolerate seeing. Watching re-runs of old movies and TV series is another time-sink.

The other advantage of moving the TV from the living room is to have real conversations with people who come to your house. Otherwise, part of the time is spent watching some sports or movie, and then you don’t get to talk with the person or exchange any meaningful information.

Other things I have unnecessarily wasted my time on

• Worrying about the future: Now I am here, I know what I shouldn’t have worried about.
• Learning stuff that became obsolete: No learning is entirely useless, still I could have prioritized better.
• Not holding people accountable: Give a man a fish, you have fed him for today. Teach him to fish…
• Training un-trainable people: Some people cannot be taught to fish, either.

Things I have should spent more time on

• Family, friends and relatives
• Learning what was truly important to my profession
• Becoming a better human being

Hopefully, I still have the opportunity. Yet, I sometimes feel really stupid about the time I wasted. If one only knew then what one knows now…

Comments (2)

By Krishna, August 13, 2007

Drat! Josh Kaufman has updated the Personal MBA reading list. Several new books have been added and a few have been removed/updated. I was not making that much progress towards reading all those books, but suddenly it has becoming an even further target. Actually, I am being silly – the Personal MBA is perhaps one of the best reading lists for managers (current and would-be).

I created a new OPML file for my favorite blogs. You can download the XML file and import it into Google Reader or Internet Explorer or your favorite blog reader. During this process, I learnt about this OPML validator (still in beta, though). I recently added a manually generated RSS feed for updates to my main website and also cleaned out my del.icio.us favorites. I still use Yahoo! Bookmarks to store most of my unorganized bookmarks, but as I get time, I will publish more of them on the del.icio.us site.

This is a bit old, but here is one of the funniest technology-related articles I have ever read. I belong to the category “people who don’t use Macs but sometimes wish they did“. One reason behind not getting a Mac is my dependence on .NET programming. I wonder if there is something for that on a Mac like the IE Tab for Firefox. (Thanks for Mahesh for the last link)

Coming to the coincidences, the first one was when I read this blog post on Coding Horror where a movie scene relating to an Alec Baldwin’s speech is referenced. I didn’t pay much attention to it at that time. When I reached home that evening, I found that the same movie “Glengarry Glen Ross” had arrived from Blockbuster, since I had for some reason added that to my waiting list. It was weird that it happened the same day.

Then, I have been listening to “A Short History of Nearly Everything” by Bill Bryson. It is not really short, as it is around 15 CDs with a listening time of 18 hours. And it is not just history, either, as it goes into discussing astronomy, quantum mechanics and geology among other things. Anyway, on this particular morning, the author was talking about the dynamic nature of the earth’s surface and internals and how Tokyo was a “city waiting to die” because it was sitting on top of a highly unstable part of the earth.

Later that afternoon, I was talking with another person about real estate prices and we got to discussing about real estate bubbles such as the one in Japan a decade or so ago. Suddenly, he changes the subject and starts asking me if I knew that Tokyo was a “city waiting to die”. That felt creepy!

Finally, I put up some new photos on Flickr. There are some photos of places in New England you may not be familiar with. Take a look!

Comments (3)

By Krishna, August 12, 2007

This is a follow-up from my previous article, The Rising Rupee-Dollar Ratio“. Whenever there is talk about the growth of the Indian IT industry, there is much lamenting of the fact that almost all the revenues come from outsourced services such as programming and testing instead of from software products. People say and rightly so, why after several years of software development experience, Indians do not have their Microsoft or Oracle or Google?

It is a mistake to say that there are no software products made in India. For instance, take a look at this listing. It is estimated that India’s product revenue potential is as high as $7 billion by 2010. Still, that is a fraction of the potential revenue from outsourcing, expected to be $60 billion by 2010.

One reason for the outcry is the fear that outsourcing revenue has less long-term potential than product development. Many people believe that with the rise of other outsourcing destinations and higher costs in India, the country will become less attractive for outsourcing. Hence, companies must invest in software products and focus less on outsourcing.

In my opinion, outsourcing in itself is not going to disappear. Outsourcing can really be termed as imports of services. Like imports of goods, outsourcing will survive as long as there is a cost advantage. Developed countries will continue to outsource as long as they can get a better deal for the same services.

Although Indian outsourcing firms will face increasing labor costs, this will level off at some point through internal company restructuring, greater automation, more people entering the IT labor market and so on. While other countries may offer more attractive costs, India continues to hold an advantage in terms of experience and infrastructure buildup over several years.

Russia and the East European countries are an interesting example here. There is a high level of superlative talent in those nations because of their high-class universities and prior (Communist-era) investment in science and technology. However, they have not yet developed the processes to effectively compete with Indian companies who had spent tons of money in software methodologies like CMM (Capability Maturity Model) and other business and management processes.

Also, India continues to boast millions of English-speaking, college-educated graduates. Particularly in South India, there are hundreds of colleges and universities crunching out computer students, not to mention thousands of smaller educational institutions teaching specialized computing languages or skills. On top of all this, there is an Indian Diaspora in various Western countries, particularly the United States, United Kingdom and Australia, not coincidentally all English-speaking countries. Outsourcing to India is not going away that soon.

But the question still remains: Why doesn’t India have big brand names for software products coming out? Leaving aside the fact that there are many other highly developed countries in the same situation, why isn’t there even a single strong Indian company in the software product marketplace despite a decade of software development?

There are many contributing factors for this state of affairs. One of the foremost problems is software piracy, leading to virtually no domestic consumer market for software products. With all due respect, I am yet to meet any Indian (in India or the United States) who is ready for pay for any software product if he or she can install it for free. This includes operating systems, databases, anti-virus products, utilities, etc. – you name it. And Indians are, without exception, the fastest adopters of any free or open-source products or services.

Ignoring the ethical implications, this has served as a huge barrier for any budding software entrepreneur in India. They cannot make any B2C products or services because there is nobody to buy them. And this situation is not a function of money. Even people who can afford to buy the software will not do it because piracy has become a socially acceptable norm. With web-based services, there is limited scope for subscription-based applications and hence there is a greater reliance on advertisements. That is probably the reason behind the sorry state of look of the Rediff portal.

This creates a bias towards creating B2B products, which seems to be the current state of affairs in the Indian software product business. The problem is that these applications are really difficult to build because the specific domain knowledge requires a lot of time and money to acquire. It is also heavily localized towards the national or regional laws and regulations. Thus it is difficult to obtain an international audience for such products.

The high and ever-increasing salaries for software professionals in India have created a significant opportunity cost for any fresh-out-of-college graduates going into software entrepreneurship instead of a high-paying job. There is also heavy social and culture pressure on young software developers to gain employment at a prestigious software company, preferably a multi-national firm. And India does not have a Bill Gates or a Steve Jobs to show as an example to prove anything different.

A problem with outsourcing companies is that, from a managerial perspective, it is not easy to manage and market services and products simultaneously. Services are low-margin, but require less sales effort once you are established. If a customer has a pain in terms of resource or cost crunch, they will outsource. Marketing products is more complex, because buying a product involves many other criteria. Think of renting vs. buying a home.

So what is the future? I would say that there is still hope. You have got to remember that unlike Western countries, most educated Indians have grown up with no knowledge of computers until they first studied them in engineering courses. Also, until recently, India was burdened by bureaucratic regulations and widespread corruption (which still exists) that restricted entrepreneurship, commerce and finance.

With increasing globalization, India will have to conform more to global standards of intellectual property. Corruption and bureaucracy are likely to decrease. The newer generation is increasingly more computer-literate and likely to contribute more in software innovation, especially with the advent of the Web as the primary development platform. Hopefully, we will see more from India in the coming years.

Comments (7)

By Krishna, August 12, 2007

I recently received an email article entitled “Stronger Rupee, Stronger India”. The essay was about the appreciation of the Indian Rupee against the US Dollar since the beginning of the year. The author’s argument was that a stronger rupee was better for India as it would make Indians less dependent on getting low-cost IT service business and force Indians to come up with innovative products.

Although I don’t want to operate as an economist without a license , I am not sure whether a stronger rupee is good for the country. There is evidence to the contrary with countries such as Japan and South Korea having worse exchange rates. A country like China keeps its currency pegged against the Dollar to avoid losing its cost-advantage.

A stronger rupee necessarily means more imports and less exports – whether that is good for India in the long run is debatable. The IT industry is a very small portion of the economic output in India, i.e., only 1% of the total GDP. And India has a large industrial and agricultural base, which could be affected by the rupee appreciation.

I do know something about the short-term impact on IT outsourcing to India, so let’s discuss that. Since the beginning of 2007, the Indian Rupee has gone from Rs. 45 against the dollar down to Rs. 40 (roughly). During the same period, salaries have sky-rocketed in India, while at the same time, there has been increasing competition from East European and other Asian countries.

This situation has led to diminishing profits in the IT outsourcing industry. The outsourced work still exists and continues to grow, but since it is primarily a service industry, the margins are becoming smaller. So while business and revenues are likely to increase, the profits will slowly hit a plateau. Such a situation is normal and expected in any fast growing industry.

The higher margins until recently had allowed vendors to maintain high bench strength and invest heavily in training, processes and infrastructure, among other things. All of these could come under pressure. Smaller vendors, caught between stagnant market rates and rising labor costs, will find it increasingly difficult to manage future growth. This will have negative effects on the Indian IT labor force.

At some point in the near future, rising salaries will hit a ceiling beyond which it is economically unfeasible to conduct outsourcing operations. Remember that outsourcing (or for that matter, any geographically disbursed development) includes several types of overhead costs both for the customer and the vendor. This means that future salary growth will be less spectacular. Highly salaried professionals will be under greater pressure to prove their value and they must, therefore, put greater efforts to maintain their advantage.

Right now, there is a big recruiting rush for software developers. And companies are not really looking carefully at the right mix of resources in terms of different levels of experience and skills. Companies are willing to pay handsomely for any person with a reasonable resume. This is due for a correction.

Companies will have to take stock and put the right mix of experienced and freshmen developers. They will have to spend more to retain such people and train them. This will mean operating lean and paying significantly more attention to resource management and allocation. Overall employment will decrease (or not increase as much) as companies learn to do more with less people.

In recent times, there has been much trickle-down of wealth because of heavy spending by highly paid software professionals - real estate, electronics, automobiles, etc. Some real estate prices have gone up several times. Much of this is speculation because such prices can only be afforded by commercial entities and not by most Indians, who outside IT, still continue to have low salaries.

If the IT industry slows, this could have the effect of slowing down such spending. Some of the corrections in the prices of high-selling goods and services could affect those sectors. In the long run, this could all even out and the economy will be stronger. But in the meantime, a lot of people stand to lose a lot of money.

But what about Indian product innovation? More in my next article…