Design in one team, coding in another

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.