So, what’s it really like working in the software industry?
So, after a couple of months I was able to implement the RFC into our code and then I was asked to ‘drive’ a demo of one of our applications that was being developed offshore in India (we had offices all over India – but the one we used was in Hyderabad).
The application itself had been developed offshore for the last 6 months, and I had only played around with it for a day. But, after just a day I had noticed some serious flaws in the application – and it wasn’t really doing what it was meant to be doing. And, it wasn’t as if I was doing anything complicated – I was just testing it out to see if what it did made sense to me, and it simply didn’t.
So, I brought these flaws up in the demo that I was supposed to be doing, and everyone looked at me like I was some sort of genius. Although, I didn’t feel like a genius at all – I had just merely played around with the application to see if it did what I thought it should do, and it didn’t. In fact, I was just shocked that no one onshore had found these things beforehand. I think that was the day when I had sort of an epiphany – there is a serious lack of foresight, planning, and communication in the software industry.
In college I thought that everyone who has a job as a full time software engineer in a big company must be damn good at their job. This is not true at all – although a lot of software engineers are very technically savvy, they lack common sense (which doesn’t seem to be too common nowadays). Many engineers will egotistically try to intimidate others with their technical jargon/lingo, but when it comes down to it a lot of them lack skills that I would consider more important than the programming skills. So, my advice to new grads is don’t be afraid to enter the software industry – with just a little bit of intelligence, concentration, and hard work you can do quite well in the industry.
Who’s to blame?
Regarding the bugs that I found, it’s hard to say who was at fault for overlooking these serious deficiencies in the product – there were a number of candidates that could be blamed: the 2 database architects responsible for giving the specifications to our Indian counterparts, my manager who overlooked the team responsible for the products, or the engineers in India who actually wrote the code for the product.
The people onshore obviously chose to blame the people offshore since they did write the code for the application. But, I think that was just because offshore was the most convenient scapegoat since they were on the other side of the globe in India. After all, onshore does run the business – so we were making the decisions.
In my opinion, the real problem was the lack of communication and checks and balances. There was hardly any communication between the India team and the onshore team – if there were more quality communication, then this problem surely would not have occurred. Also, there were no frequent reviews of the product being developed in India – the architects simply gave them a document with the specifications of what was required, and then let the India team go to work on it. Only after 6 months did they find something that they could have found within a month if they were doing more frequent reviews of the product.
Walk in an Indian man’s shoes
I think that people onshore would benefit greatly if they could try to understand that offshore counterparts simply don’t get the day to day exposure to the business needs that only someone onshore could. So, naturally offshore can’t be expected to understand everything that someone onshore could unless there’s good communication. This means that outsourcing is most effective when valuable information is shared and offshore feels like they have some ownership and responsibility in whatever they are working on.
Of course, offshore has a responsibility as well – a relationship can’t work if it’s just one side putting in all the effort. The biggest weakness that I’ve see from working with offshore is the lack of questions that offshore has for people onshore. I think this may be because sometimes people offshore are afraid to offend people onshore with any ‘dumb’ questions – but this fear should not be present. Because, if the job is going to be done right, then any questions an offshore person has must be answered.
I also think that many people in offshore just don’t really feel like a part of the business – sometimes they may feel like outsiders who are just given the most undesirable work. The responsibility of software engineers working offshore is to try their best to understand that any work given to them is critical to the success of the business. Having used offshore resources extensively in my 2nd job for very important/business critical applications, I know this from experience.