Quality of offshore code

[Sania Marsh]

Question to those here who share projects with offshore folks.
How is the quality of code you recieve from overseas?

[Don Stadler]

Sometimes horrible, sometimes OK, rarely particularly good.

[Roger Chung-Wee]

I have found that the quality varies tremendously, from very good to very bad. Generally speaking, the code is of lower quality than I would like to see. Obviously, the quality of the programmers is very important, but there is one factor which is often overlooked. If you work with an offshore team, you are usually in catch-up mode, having to influence the quality of the code after it is written. Ideally, you should be working with the team in your physical location, which would enable you to influence the quality of the code much sooner and much more easily.

I think that sending work offshore should only make sense if you cannot get the skills onshore, but what management sees is only the lower quoted cost of offshore working. What they do not see is the cost of lower quality work, which usually occurs over a period of many years following the end of the project.

[Jogi Poonawala]

How does it matter which side of atlantic (or pacific) your team is :-) .. It totally depends on the kind of resource you have on either side.. if you have junior/ inexperienced resource then the chances that the �quality� of code will be low are high.. but that�s true for onsite as well as off shore.. if you are willing to pay good money and employ good / experienced resources then definitely you will get �good� quality code.. this again is true for onsite as well as offshore resource�

[Kj Reddy]

Atleast in my company we dont see any difference between the code developed in offshore and onsite.

[badari gururaj]

I work as a support lead. My team is responsible for bug fixes. The code is developed onsite and we support it offshore.
I have seen quite horrible code written and some very very good code written. I have seen some very basic mistakes made by senior developers.
I feel what really determines the quality of the code is the coding practices, review procedures, testing practices and sometimes just sticking to the project coding standards.

To answer your question, i have seen some bad quality code done overseas.

[Vedhas Pitkar]

Yes, it all depends on the person who is writing the code & what state of mind he/she's in. Anyone can write bad code, but for writing good code you need to have an in depth knowledge of the programming language as well as the business funtionality.

[fred rosenberger]

My company once hired a U.S. company to port some code from VMS to Unix. what was delivered was so bad they threw it all away and gave up the project entirely.

My point is i don't think you can say "Offshore agencies deliver good/bad code". it's going to vary from company to company, and even team to team within a given company.

Not that i have any evidence to support this, but i refuse to believe you can make any generalization on "offshore code".

[Kj Reddy]

Its true. The quality of code depends on person, team and company and their practices. It wont depend on country.

[soniya saxena]

one of the problems is lack of experienced technical resources in India. most people do not want to code beyond 3-4 years. after that they get into leadership positions. In IT services based companies, there is little scope for a technically experienced person, say 8-10 yrs. There might be scope for him in terms of work, but then he might have to work with 3-4 yrs experienced guys at a similar pay.

[Mark Herschberg]

Two side comments:

1) The advantage of offshoring is not just potential cost savings. The is some advantage to a 24 hour team--although I think this can be limited for a unified development project. Also, it can allow you to more easily scale up development. There are companies in India with thousands of software developers such that if you have a team of 10 people, and need to double it to 20, you can do so in a matter of weeks. There are not software focused companies like that in the US which have a resource pool that large.

2) While clearly the answer will vary, it is equivalent to asking...
- How strong are developers with 3-4 years fo experience?
- How good has outsourcing your IT support services been?
- How easy was it to port from Java to C#?
All of these questions have a "your milage may vary" aspect to them based on the particular vendor picked, but in general, it is a valid question to ask. There are a very tiny number of developers who after 3-4 years can architect a small project, but I'd say most of them can't. It seems a valid question to ask then, if you're looking for an architect, because then you will exclude such candidates from your search as they are an inefficent path to follow. Of course anecdotal evidence isn't the most systematic way to approach such a question.


--Mark
[ June 15, 2005: Message edited by: Mark Herschberg ]

[Sania Marsh]

I asked this question just because I'm so dissapointed by the code we get from offshore resources.
It takes then more than 50% of the same time to spend fixing really dirty stuff.
I myself have only 4 yrs of experience, but I know how bad it is to copy code over into 30 pages and that data should not be hardcoded into presentaion.
I get 400 lines long jsp pages that make calls to databases and process the logic, while it is very clear from all other classes and beans how jsp should be used in this project, all they had to do is spend more time to understand it.
After all I feel like I have to clean muddy room, while it could have been started all clean. I build faster than fix someone eslse's logic(even though I wouldn't call it logic), why couldn't I just build it myself?
I don't want to complain to management about this, but it all comes down to overtime for me.
And it seems like they are smart guys, they just are too lazy to do things right.
It seems like some of you do, actually, have good experience outsourcing, maybe we should just try pushing on those guys harder, maybe ask management not to even let their code come to us(onsite developers), unless it passes onsite QA passing all rules.
I think it is worth getting one developer shifting to QA, particularly for this reason and maybe in few months it would teach those guys something.
On the other hand, will we have enough time pushing the code back and forth??
Ah, it's just upsetting.
[ June 15, 2005: Message edited by: Sania Marsh ]

[Mark Herschberg]

Originally posted by Sania Marsh:

I don't want to complain to management about this, but it all comes down to overtime for me.

Then you're not really helping the situation.

There's a great system dynamics simulation, The Beer Game. In this game, you try to run a simply supply chain. Everyone plays it badly. By everyone I mean tens of thousands of people over the last few decades including school children, college students, MBAs, and many, many corporate executives. This are people who run billion dollar companies and yet commonly do a factor of 4-10 times worse than a dumb strategy (one which could be replicated by 2 lines of code).

The lesson of the game is that often smart people get bad results in complex systems. Having run outsourcing projects myself, I try first to consider the system as the source of problems. Look at the process. Why did they make the decisions they did? What did/didn't they know that caused them to make that decision and not a different one?

How often do you communicate with them? In what ways? Have you spent time at their site? Have they spent time at yours? Do you have a defined process? Is it more formal/involve more communication than a process for the equivalent project done by a single site team? Do you have coding standards? Do code reviews? Follow other best practices?

Are you regularly improving the process? Do you do post mortems?

Food for thought.

--Mark

[peter wooster]

I've seen cut and paste code from onsite juniors. This is a common coding practice of those with little experience or under extreme pressure or both. One piece of code I reviewed had over 50 calls to DriverManager.getConnection, and it was just a simple Swing based document management system. It worked and was delivered quickly, but would have been very difficult to change to use a different database.

The quality of outsourced work (offshore or otherwise) varies with the amount of money that management is willing to pay, the quality of the requirement spec, and the degree of time pressure. There are offshore developers who provide high quality, of course they cost more than the bottom line friendly shops and may take longer.

An old sign from the print shop

You want it cheap, you want it fast, you want it right.
Pick two.

[Vedhas Pitkar]

Originally posted by Sania Marsh:
I asked this question just because I'm so dissapointed by the code we get from offshore resources.
It takes then more than 50% of the same time to spend fixing really dirty stuff.
Ah, it's just upsetting.

Who is your offshore IT vendor?

Hope its not my company.

[Kj Reddy]

Originally posted by Sania Marsh:
I asked this question just because I'm so dissapointed by the code we get from offshore resources.
It takes then more than 50% of the same time to spend fixing really dirty stuff.
I myself have only 4 yrs of experience, but I know how bad it is to copy code over into 30 pages and that data should not be hardcoded into presentaion.
Ah, it's just upsetting.

[ June 15, 2005: Message edited by: Sania Marsh ]

I strongly feel that, the kind of coding doesnt dependent on offshore or onsite. The good/bad quality coding will be developed on both sides based company practices, team members experience level. But for that you cant blame offshore.

[ June 16, 2005: Message edited by: Jagdish Reddy ]
[ June 16, 2005: Message edited by: Jagdish Reddy ]

[Arjunkumar Shastry]

Although quality might be independent of offshore/onsite,chances of offshore shops delivering lower quality are higher if proper precautions are not taken.Many offshore companies claim big things at lower cost,get the project and hire people randomly and put them on work.

[Anand Prabhu]

Originally posted by soniya saxena:
one of the problems is lack of experienced technical resources in India. most people do not want to code beyond 3-4 years. after that they get into leadership positions. In IT services based companies, there is little scope for a technically experienced person, say 8-10 yrs. There might be scope for him in terms of work, but then he might have to work with 3-4 yrs experienced guys at a similar pay.

My last experience with an offshore development team concurs with your assessments. The team had a project lead, technical lead, senior and junior programmers. Though the seniors were knowledgeable and each member of the team had their strengths, they were not good in integration. The senior members had a coding experience of 3-4 years max and they were climbing the ladder to "lead" positions. So when we challenged the architecture as it did not fit the needs for an intense transactional system, many of them couldn't come up with good solutions. And the code written by the junior and senior developers was miles apart. Eg:In one situation, a count had to be incremented based on a condition. Of course, everyone would use an "if" statement. But, the code threw an exception when the condition was met, caught that exception and the variable was incremented in the "catch" block. It was obvious that a new programmer trying to learn Java was coding that. But this code should not have passed their quality gates and come to us. Their Version Control and Change Control were a mess or non-existant. And they constantly claimed that they were a CMM level 5 compliant company.

Of course, we had headaches with systems outsorced to local vendors but that was another different ballgame.

[Jeroen Wenting]

Very similar to my experience with offshored projects.
If they deliver at all it's late, poor quality, and usually incomplete.

I'm getting extremely worried about the company I now work as upper management has discovered outsourcing and are extatic about it. After a single visit from a bodyshop in Romania they've already decided to contract 500 hours of work there, and suddenly major efforts are started to introduce UML, quality reviews for design documents, and statements about how the company is to become a "knowledge company" instead of a "software company" are becoming ever more frequent.

[Jogi Poonawala]

I think the quality is affected by "inexperienced" team as against "offshore" team. And IMO its not correct to generalize the quality of work based on the geography. You can get good results from any team provided you ensure that team members are competent enough. Even if you are outsourcing your work to CMM level 5 company, you can always ask for a brief technical chat with the team before you actually give them any work. But that�s true for onsite teams as well as offshore teams.
One reason why the offshore team gives poor quality only because it sits on the other side of ocean is because of communication gap. It may not be possible to communicate your expectations / standards / processes / quality gates etc effectively to your team members who are 5000 miles and 10 hours away from you� but then again these can be eliminated by careful transition plan�

[Mark Herschberg]

Originally posted by Anand Prabhu:

But this code should not have passed their quality gates and come to us. Their Version Control and Change Control were a mess or non-existant. And they constantly claimed that they were a CMM level 5 compliant company.

CMM5 just means the company has a well followed process in place and that includes proactive improvement. It does not make any claims about the inherent quality of the work or speed at which the improvement occurs. It just promises low variability across projects.

--Mark

[Anand Prabhu]

Originally posted by Mark Herschberg:


CMM5 just means the company has a well followed process in place and that includes proactive improvement. It does not make any claims about the inherent quality of the work or speed at which the improvement occurs. It just promises low variability across projects.

--Mark

True. That is the definition of a CMM Level 5 company. I was just referring to the company that I worked with and our experience with them. When we wanted an earlier version of the code because their current version was having problems, they could not come up with any. When we noted that there were many functionalities in the product that was not in scope and asked whether they followed any Change Control Process (Scope in this case), they went on a finger pointing game. We had many such issues. And in each meeting, their response to our concerns were the same: They were a CMM Level 5 company and they were following well defined processes.

I am not generalising on the offshoring/outsourcing arena. That can consume volumes. I am recounting a bad experience with a vendor who had an offshore team. We had similar experiences with local vendors too. And of course, we had some internal projects that failed too. For each, the reasons for failure were different.

[Tim Holloway]

Originally posted by Mark Herschberg:
Two side comments:

1) The advantage of offshoring is not just potential cost savings. The is some advantage to a 24 hour team--although I think this can be limited for a unified development project. Also, it can allow you to more easily scale up development. There are companies in India with thousands of software developers such that if you have a team of 10 people, and need to double it to 20, you can do so in a matter of weeks. There are not software focused companies like that in the US which have a resource pool that large.

The 24-hour project is highly overrated. It's certainly good if you can run teams of manual testers around the clock, but the most critical part of the project is in the design phase. This is a highly creative process where decisions are made, weighed, and tossed away until something workable comes out. For many of us, it's already a 24-hour process. I'm not the only one here who's confessed to having a significant piece drop into place in the shower or at 4 am. You can pass ideas around the globe, but the magic moment when it clicks comes on its own schedule. Neither the DNA spiral nor the benzene ring came out of a pre-planned scheduled process.

And since, despite all attempts to reduce the coding phase to a mindless process, there's still creativity involved on the part of even the lowlisers junior programmers on the largest teams, that makes the 24-hour development concept pretty much a loss.

Fred Brooks aleady had his say on the dangers of trying to upscale project teams too fast. The nice tidy one-line version of Brooks Law has found to be less than universally true, though it's accurate enough in the main.

One thing Brooks didn't factor in, however, was the added complexity of bringing in people of a different culture who have no long-term stake in the project or the organization. And when I say "culture" I don't just mean offshoring or East/West, I also mean corporate cultures, which, if anything can be ever worse, and be available without ever leaving the neighborhood.

[Roger Chung-Wee]

I think the quality is affected by "inexperienced" team as against "offshore" team. And IMO its not correct to generalize the quality of work based on the geography. You can get good results from any team provided you ensure that team members are competent enough. Even if you are outsourcing your work to CMM level 5 company, you can always ask for a brief technical chat with the team before you actually give them any work. But that�s true for onsite teams as well as offshore teams.

You can chat all you like with the offshore team, but that does not stop their manager from changing team members. With an onshore team, you can much more easily check out competencies and see what is happening with the makeup of the team.

One reason why the offshore team gives poor quality only because it sits on the other side of ocean is because of communication gap. It may not be possible to communicate your expectations / standards / processes / quality gates etc effectively to your team members who are 5000 miles and 10 hours away from you� but then again these can be eliminated by careful transition plan�

I'm inclined to think that a remote working may make sense if all the offshore workers are doing is a task which is repetitive. Maybe punching cards from COBOL coding sheets (I am showing my age here).

But if it's a project, that's another ball game. In my experience, you can never really overcome the problems brought about by the remote location of a team, which often knows nothing about your business. You just cannot communicate everything you know to people who are thousands of miles away. There is no substitute for working with a team in your physical location (and therefore also in your time zone). I just wish more people in authority realised this.

[Mark Herschberg]

Originally posted by Tim Holloway:

The 24-hour project is highly overrated. It's certainly good if you can run teams of manual testers around the clock, but the most critical part of the project is in the design phase.

I by no means claim *poof* your triple your productivity, but that for certain types of tasks, there is an advantage. Design isn't one of them. And while we are supposed to spend 30% of the time designing and 30% coding (or pick your favorite numbers about good practices in theory) the reality is it's 70-80% development. Design generally isn't the big time sink of your project. (I don't want to debate if that's right or not, that's for the process thread.) For certain projects which can be relatively decomposed, then it works well.

Originally posted by Roger Chung-Wee:

You can chat all you like with the offshore team, but that does not stop their manager from changing team members.

No, but you know what works much better than talk? A contract!

Seriously, before my outsourcing partner makes any staffing changes, it goes through me. When I need additional staff, I have them send me resumes, and then I interview the candidates by phone. This is the policy we set, and they follow it. It's not that hard. (Obviously I can't do anything about their guys who leave that company to work elsewhere, but all other cases go through me.)

Originally posted by Tim Holloway:

But if it's a project, that's another ball game. In my experience, you can never really overcome the problems brought about by the remote location of a team, which often knows nothing about your business. You just cannot communicate everything you know to people who are thousands of miles away. There is no substitute for working with a team in your physical location (and therefore also in your time zone). I just wish more people in authority realised this.

There is no substitute for having someone on site with you. There's also no substitute for a differential of, say, $50,000 a month. Engineering, unlike science, isn't about perfection, it's about "good enough." As an engineer you are concerned with the quality of your product. Managers are concerned with that, as well as hitting market windows and staying within budget. Many places screw up outsourcing. Others do benefit from it.

--Mark

[Sania Marsh]

Originally posted by Mark Herschberg:

How often do you communicate with them? In what ways? Have you spent time at their site? Have they spent time at yours? Do you have a defined process? Is it more formal/involve more communication than a process for the equivalent project done by a single site team? Do you have coding standards? Do code reviews? Follow other best practices?

Mark, Those are very good questions, I think the management is trying to do things right, but I am noone here to make decisions of this level.
We talk to offshore whenever we need. Need to keep asking for progress to keep it rolling. If they run into issue they don't try to fix it, rather they shoot us an email and wait for the call. If it takes me 5 hours to call them, there will be no progress during that time on their end. 90% of the time I can understand and explain how to fix their bug over the phone in 15-30 min. No code reviews (in my 4 years of development experience I have never seen any code review). Noone has time to check how clean and correct the code is. QA can check some simple stuff, like number of lines in method and indentation, but not the complicated logic. And even for that they got no time now, because there are too many critical issues where something just doesn't work, so their main goal is to get it to work and after, they are too tired and out of time for "little" stuff like quality of code.
Developers onsite are complaining to each other, I think we will have no choice but to raise this question on next meeting with management. If it will keep going same way, I'm afraid we will start loosing people.

[Mark Herschberg]

I recommend the following strategu for you

1) Find a champion
You believe there is a problem. You need to make them believe it. You need to find one person with influence/power that something needs to change.

2) Educate the champion
You and s/he should look for solutions. Consider the questions I asked. Look at books, web sites, or talk to experts in the field for some guidance.

3) Formulate a plan
Start simple. Put a few key steps into practice. See how they go, get feedback, tweak. Repeat.


Heck, start by showing them the list of questions I asked (type it up an email them), and say "this is a guy who runs outsourcing teams and when hearing of outsourcing problems this is the set of questions he recommends asking."


--Mark

[Jogi Poonawala]

I have seen onsite-offshore model being successful. I was part of their transition team 3 years back.. It was a midsized US based company. When in 2001 they decided to offshore their work, they did careful planning�
They had build their own framework, platform which they use for all their projects with some customization.. One of their very senior person came to India and trained offshore team for 1 month.. It was regular classroom training.. theory in morning session followed by assignment in the afternoon session.. one month training was followed by 1 week assignment.. all the team member�s assignments were carefully checked.. then the guy had one on one talk with each tem member..he then picked leaders from the gang and assigned them their team.. then all the team was flown to US for 3 months on the job training.. within 3 months everybody was very well aware of the process, standards, quality gates etc.. they also got to know their counterparts in US and vice versa.. then after 3 months the team was again flown back to India in phases.. once in India.. Team leaders were responsible for the work allocated to their team.. there were obviously weekly meetings, daily status reports, use of yahoo/msn/aol messenger for quick communication / net meetings.. this was complemented by good HR policies like spot awards for team member� at /above par compensation, reasonable work pressure etc..
The end result was very agreeable to the onsite company as well as their off shore partner.. so much so that they are now in the 4th year in operation.. And no it was not some repetitive job.. it was latest technology job involving integration with lot of other systems..

The point is offshore projects run a risk of failure because of communication gap which can be eliminated if planning is done properly and execution is done sincerely.. but they don�t fail because the quality of offshore work is poor..
[ June 17, 2005: Message edited by: Jogi Poonawala ]

[Dave Lenton]

Does copying and pasting code from an American website *cough*JavaRanch*cough* to my computer in the UK count as outsourcing some of my work?

[Sania Marsh]

In fact, Mark, I am going to pass those questions to senior guy who is very friendly with developers, and at the same time has influence on how things are done. I'm just going to ask him to answer all of those questions for developers first.
And Jogi, your company made very smart move by bringing team to US, I think offshores don't take seriously visits of US developers , bringing them to US for 3 months makes them do same and as much work as US team does, which introduces the quality and quantity of work they should do.

[Anand Prabhu]

Originally posted by Jogi Poonawala:
I have seen onsite-offshore model being successful. I was part of their transition team 3 years back.. It was a midsized US based company. When in 2001 they decided to offshore their work, they did careful planning�
They had build their own framework, platform which they use for all their projects with some customization.. One of their very senior person came to India and trained offshore team for 1 month.. It was regular classroom training.. theory in morning session followed by assignment in the afternoon session.. one month training was followed by 1 week assignment.. all the team member�s assignments were carefully checked.. then the guy had one on one talk with each tem member..he then picked leaders from the gang and assigned them their team.. then all the team was flown to US for 3 months on the job training.. within 3 months everybody was very well aware of the process, standards, quality gates etc.. they also got to know their counterparts in US and vice versa.. then after 3 months the team was again flown back to India in phases.. once in India.. Team leaders were responsible for the work allocated to their team.. there were obviously weekly meetings, daily status reports, use of yahoo/msn/aol messenger for quick communication / net meetings.. this was complemented by good HR policies like spot awards for team member� at /above par compensation, reasonable work pressure etc..
The end result was very agreeable to the onsite company as well as their off shore partner.. so much so that they are now in the 4th year in operation.. And no it was not some repetitive job.. it was latest technology job involving integration with lot of other systems..

The point is offshore projects run a risk of failure because of communication gap which can be eliminated if planning is done properly and execution is done sincerely.. but they don�t fail because the quality of offshore work is poor..

[ June 17, 2005: Message edited by: Jogi Poonawala ]

From your post and that of Mark's, it is very clear that the major reason for success were well defined processes that everyone cooperated on and implemented. Our failure was because the business just wanted to maximize their profits without doing the homework. They did not crosscheck the vendor's claims. The vendor promised them the moon and reasoned that all they had to was to develop a product, demonstrate the product and the functionality to the client, deliver the code to us, not worry about implementation on our environment, collect their invoices and move on. The business and the vendor just bypassed us in design, planning and coding. They just wanted to involve us during testing and closure (with code handover). Many a times, we pointed to both the business customer and the vendor about the dangers ahead. But both had their own agenda and the end was a disaster for all of us.

[nils appeldoorn]

Originally posted by peter wooster:
An old sign from the print shop

You want it cheap, you want it fast, you want it right.
Pick two.

so old and soooo true!