This week I went to Bangalore, India, to better understand aspects of off-shoring maintenance, development and test work within a software development team.
Bangalore is, as you may know, a central hub for a large population of well-educated, well-trained and ambitious engineers within software development.
In TIA we are considering how to tap into this in relation to our development work and not at least maintenance of the released versions.
Arriving at Bangalore it is clear that India is nowhere near anything like the small country of Denmark, from where TIA origins. The Indian population is huge, the chaos (at least in traffic as I saw it) quite overwhelming, but you also get the impression, that these are people who wants to achieve a lot. Ignoring the occasional cow that disturbs the flow of traffic, the strategy of the Indians seems to be to always look for the best way of moving forward and then just go. Every inch of asphalt is being used. The infrastructure of Bangalore still is leaving something to be wished for, but I did not see any real serious jams through the intersections…
The visit for me was a confirmation, that if you select the right partner you will not just get access to a pool of resources; there is a good chance that you may even learn a thing or two. The operations we saw was certified at CMMi level 5, had several thousand engineers residing in the buildings and hired another thousand people across it’s locations in India each month.
The point of this is that when considering using off-shoring resources it may actually not be a question of whether they are up to the task, but whether you are.
Previously the word has been that Indian IT resources may be technically good, but did not know posess any domain knowledge. As far as I can tell even this is quickly changing. Partly because specific domain knowledge is fast being built up through on-the-job training working with domain issues – also within Insurance. And partly because it seems to be getting increasingly more interesting for Indian born people who have been living and working abroad for many years, to return to their native country; and with that – bringing back strong experience and domain skills.
Off-shoring any work requires that you start with realizing you have to be very structured with your requirements. You should know and describe exactly what you need. Over the last 20 years I don’t think this has been the most popular way of developing software for many programmers. What the heck – let’s talk to the customer and write the code – it’s way more fun than writing documents. Well - I certainly understand why programmers would prefer to spend time writing code as opposed to writing documents. I actually think we should work hard to let them do just this – writing code. Which again basically means that we should have someone else writing the requirements specifications! And those guys need to understand the business. Being more strict and structured in the requirements work is a good thing whether considering off-shoring or not. But if you want to send work abroad and work with people trained and working at a CMMi level 5 you better be good at it.
Another aspect I was interested in was the approach around testing. In India testing seems to be just a prestigious career path as programming, with several skill levels from junior test engineers to highly esteemed test architects. This is definitely hard to find in the Nordic region, where it seems that many people find testing a second rang discipline. From my experience, there is absolutely nothing second rang about testing highly complex business solutions – especially within the Insurance industry. This requires a solid technical background mixed with a passion for quality, building and using the right toolsets and finding those highly costly bugs in the products.
My conclusion from the short visit to India is that we should strive to be able to tap into this pool of resources. And we should use it as a way to improve our own internal processes and turn software development even more into a predictable process. One where creativity is applied at requirements and design time, but not to actually getting the things coded, tested and brought to life. The latter are disciplines where you do not need creativity but predictability. And in the end this is what I believe customers are looking from their vendor. Predictable features, at a predictable time, in a predictable quality. And so – it’s all about predictability.
At TIA we will be using off-shoring going forward – would you?