I will be involved in a project where all the software design is made by a local team and these designs are sent to an offshore team for coding.

This is the first time I face a project with this characteristics and for me it feels kind of odd: The managers expects us to make very detailed design documents so there's no space for error for the offshore team; from my perspective they are making us coding in paper while we can do it in an IDE.

So, my question is is this approach good, or proven right? What are the main considerations our software process has to have to have success in our project?

  • 11
  • 5
    @mike: Spacecraft software is a little different than most software. It has to work perfectly all of the time, or loss of life and extremely expensive assets can occur. See fastcompany.com/28121/they-write-right-stuff Commented Aug 1, 2013 at 16:36
  • 9
    I guess the offshore team is cheaper, is it also twice the size of the design team? Does it have some real advantages over the in-house team? e.g. do they speak the natural language of the final users while you don't? Do they have some sort of talent you don't have in-house? If not, I see your company has a bad case of PHB poisoning.
    – ZJR
    Commented Aug 1, 2013 at 16:41
  • 1
    @mike: I think it would be more accurate to say that in most software a small number of bugs is considered acceptable, because bug-free software is an asymptote and getting those remaining bugs out is very expensive. Commented Aug 1, 2013 at 21:54
  • 10
    I suggest that you start looking for another job immediately. Programmers are not interchangeable cogs, which is the underlying assumption of this sort of arrangement. Separating design from development in this manner - onshore or offshore - guarantees a disconnect between the customer and the developers that makes failure highly likely. Commented Aug 2, 2013 at 6:33

5 Answers 5


My opinion:

If all you'll give the offshore people is documents and diagrams, you will have a lot of miscommunication and disappointment.

My recommendation

  • Don't give them so many documents, but rather interfaces and abstract classes in order to straitjacket them into your design goals.

  • Require them to use a known naming standard.

  • Require them to use unit tests.

  • Send one of your designers/architects offshore to their premises to supervise the process, it will still be cheaper than coding in-house, but you will get better results.

  • 2
    Offshore teams don't work the way onshore teams do. You have to be very, very specific about exactly what you want, otherwise you won't get what you want. Commented Aug 1, 2013 at 16:39
  • 32
    ... Which is part of why a lot of development is coming back onshore to the U.S.; this approach of designing onshore, developing offshore, then debugging back onshore pretty much requires you to have the same onshore resources you'd use to develop the entire thing soup to nuts in the first place. In any other production process, where direct materials and labor of making the thing are high, the offshore approach makes sense. When the design for what you're making is not only the majority of your cost, but might as well be the end product, offshore development becomes more obviously redundant.
    – KeithS
    Commented Aug 1, 2013 at 17:09
  • @KeithS Great comment. I agree %110 with you. Commented Aug 1, 2013 at 17:44
  • 2
    Forcing them to use classes and interfaces you came up with without having written any code yourself is a recipe for disaster. Commented Aug 2, 2013 at 7:34
  • 2
    @Euphoric There's a long stretch between writing abstract void calculateDroneTrajectoryBasedOnCNNNewsFeed() and actually implementing it. Commented Aug 2, 2013 at 9:50

It's called Big Design Up Front, aka Waterfall. It's not widely regarded as a highly successful methodology. But I've seen it work, and when it does work, it works very well. It's very expensive to do right.

It's also what your employers have asked you to do.

Offshore teams don't work the way onshore teams do. You have to be very, very specific about exactly what you want, otherwise you won't get what you want.

  • Can you detail a little bit more on "very specific"? Did I have to get to the level of include method pseudocode? Commented Aug 1, 2013 at 17:27
  • 8
    Pseudocode will improve your chances of getting code from the offshore team exactly the way you want it. As others have pointed out, the process of making offshoring work successfully can be more costly than just keeping all the work in-house. But that's not your decision to make. Commented Aug 1, 2013 at 17:28
  • 2
    Shouldn't that be It's very expensive when it goes wrong. :-)
    – LarsTech
    Commented Aug 1, 2013 at 21:34
  • @LarsTech: Which is why the additional expense of doing it right is justifiable. Commented Aug 1, 2013 at 21:55
  • Pseudocode like to take the same effort as to write real code, + offshore communication overhead
    – Web Devie
    Commented Aug 2, 2013 at 9:44

The last project I was the software designer. All development was offshore. We were successful. So this process can work.

I did produce a lot of documentation but it was by no means comprehensive and by no means step by step instructions or detailed down to class names, function names etc. For example, I produced sequence diagrams, use case, workflows, system, and integration diragrams, as well a more detailed design documentation as needed.

It really depends on how much you trust offshore development. I trust my offshore team to be competent developers. That said, I provided overall direction but gave them leeway to implement which the offshore team found pleasantly satisfying. In the past they were more micro-managed. In certain situations I would guide them using the design patterns as needed. I also regularly performed code reviews and analysis on the code they wrote and would advise refactoring or clean up efforts. Also, since some of the team had accidents with recreational vehicles I ended up coding some of the stories during implementation since we ended up being short on some resources.

Additionally, I think this process really only succeeds on the strength of your technical lead(s) on the project and the communication between business, designer, leads, and developers. We did spend a lot of time going over each feature and story and made sure that the offshore leads/resources were well versed on to what the requirements were. If they are not asking questions during the review of the feature/story then expect some issues. Also work wasn't considered complete until there was business signoff. So that made everyone accountable since everything was tracked in a tool that managed agile development.

As one of the other answers has alluded to already, the development process included naming standards (resharper rules built in), test case coverage (it used TDD, Mocking, etc) so if there is good coding process and procedure in place it will increase your chances for a successful project.

  • Do you use any particular agile process? A tailored one maybe? Commented Aug 1, 2013 at 19:07
  • 2
    It wasn't pure agile, more like planned iterations. Everything was planned up front and then chunked into 2 week iterations. We used agile processes across each interation. Velocity and burn down charts used, standard daily stand up followed by a hour or two phone call offshore. Definately spend a lot of time on the phone to offshore, but our ideal development day was 6 hours to account for communication time.
    – Jon Raynor
    Commented Aug 1, 2013 at 20:59
  • 2
    Note to self: eliminate recreational vehicles from future software iterations. Commented Aug 1, 2013 at 21:56
  • Do you believe that your success had more to do with picking the right offshore team, or simply trusting them to do the right thing without micromanagement? Do you think your "planned iterations" technique was critical to your success? Commented Aug 1, 2013 at 21:58
  • 1
    @Jess - No, the team is only responsible for delivering on approved stories and features (functionality). Future functionality is not delivered, although the design of the software usually allows for flexibility of some sort but we only deliver what was asked for.
    – Jon Raynor
    Commented Aug 19, 2013 at 16:29

The major cost of the offshore development is the communication. Documentation is one way of communication, however, documents are not able to cover all the details and potential changes usually.

Not sure how big your project is. I am assuming it's big otherwise it's not valuable to use the offshore development team. Thus, my experience is

  1. Define the skeleton code, public interface, service interface, etc., and review together
  2. Define the acceptance tests with the other side
  3. Split the big document to small stories, work based on the small stories. The big document is just a big picture of the whole system
  4. Set up the check points of the stories, one week or two weeks

1 and 2 is actually about the development, to make sure the other side understand the requirement well, and both side are using the same pattern. 3 and 4 is a part of agile development methodology, but for the offshore development, it's hard to use the full agile process.


I think to some degree we all work like that. Someone somewhere design something and we code something that's part of or work with the system. Examples are building apps based on a framework, like non-game apps on mobile devices. A lot of UI decision has been made by the design team of the people who built the framework. They controlled everything from learning to write an app to selling your app. If you want to look why this model was successful, just look at the amount of documentation and tools provided by some vendors.

Another example is web applications with lots of them trying to implement REST style. This one doesn't really tell how to implement something, although when there are specifications on how to use HTTP. Anyway, there are specifications and guiding principles to follow. If you see the amount of discussions about REST implementation on stackexchange or in workplace, it's like there's an architect telling people to implement something in certain ways. It's still a succesfull model, I think, with so many people following the style.

From those two examples you can see how designs are propagated, some as paper specifications, others come with books, tools and examples. You can see how people asking (in volume), trying to get the understanding right with different degrees depending what standards/designs they're trying to follow. Just go to stackoverflow and watch ;)

If you give me your specification I will ask. If you give me unit test, I will code and test.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.