Culture issue in the Indian services industry ?

Here are some thoughts I shared with my development teams yesterday. ( I work in a software services firm based out of Chandigarh, India). Some of these might be unique to my organisation, but some are definitely very common in the Indian services industry, specially the first one.

These few thoughts, to me, are the undercurrents beneath a number of issues and problems that we keep getting into at work.

Does this sound familiar ?

The customer is better than us: (also known as the customer is happy with this)

To me, there really is no basis for this, other than perhaps that we are giving the customer what they have done in the past, or what they are happy with. But there are lots of pitfalls in that reasoning. The badly designed code supplied by the customer could have been written by a fired employee/contractor. It could have been written by employees new to the technology when they wrote it. Current team at the customer could be replaced by people who know better. Any customers expect us to be masters of our technologies. At , we have had a customer who knew nothing about junit, so there we no requirements to write junit tests. But he heard about it in a conference, and was rather angry at us for not having suggested its use ourselves. This customer had been very happy till then!

Ultimately, in today’s world, most often, most ideas can be argued. And with google, you can also add references to support your position!

2. Everyone here does it this way, so this is right: (also known as: in all my jobs, everyone has done it this way): Your universe is too small here. Try google to find a bigger universe.

A lot of this is also related to #1: most places that you have worked at probably also suffer by number 1, specially as most work in India is maintenance/support work, where you live with what you get.

3. The app already has it this way, so we should continue doing it the same way: Consistency of implementation is important, but not in all situations. Think through whether consistency brings you some advantage beyond just consistency. In most cases, it does not, specially if the existing approach is just bad. Having a consistent style of braces is useful, because it is only a matter of style. But eating up exceptions is plain wrong. I can present other reasons, but I think this should be enough.

4. Ctrl-C Ctrl V, (also known as: I’ll copy this design without understanding its context): Sort of self explanatory. We look at a design/implementation approach at one place, and copy it blindly into other contexts. When confronted with a why?, we often only have the answer that this is being used at place x. That’s no answer. If you agree with it’s use at place x, AND you can argue that x and your place are similar, ONLY then is it a valid answer, otherwise not.

5. Google does not exist (also known as: we can’t look for other opinions/ head in the sand/ how do I validate this): Fortunately, google does exist.

6. The problem will go away if I ignore it (also known as: no one else will notice it): unfortunately, someone always does!