Some Different Approaches to Integration

"Customers buy this as a single product, so think of it as a single product!"

The recommended approach if you want to make a change that you know will break other people's code (and it's your responsibility to test for that as far as possible), then you should communicate (not a one-way email) with the people involved and agree which of the methods below you are going to use to minimize disruption to the rest of the organization.

Example

Vivek wants to remove a method named getFunky() from a class used by the Client, and maybe by other components.

1. He makes his changes in his sandbox and checks that they work, then builds as much of the whole product as he can.
2. He notices that as expected he will break the Client
3. Just to make sure, he also looks at the Javadoc or uses Eclipse to identify other users of the method, and finds out that the Manager now uses getFunky too. Good thing he checked!
4. He communicates with two developers who are comfortable with changing the affected code in the Client and Manager, and together they decide how to make the necessary changes (see the choices below for some ideas)
5. Just to repeat the obvious - an email sent to a group and gets no responses is not communication, it's just a feeble excuse at teamwork. Integration requires two-way exchanges.
6. The changes are committed and life moves on.

No prizes for guessing that I don't think much of approach #2 (Break the Build), but if you decide to do this, make sure that you mail all-eng@example.com so that everyone else in the team is aware and isn't inconvenienced by the broken build.

Handy tip: your local address book may show who is in each email alias

Different Approaches

1. Don't remove the existing functionality, just add the new functionality

Pros: Nothing should break

Cons: Can be fiddly to get right, leads to overly complex code that eventually needs removing anyway

2. Check it in, break the build, and wait for other people to fix it

Pros: Quick and easy, for you at least.

Cons: Can bring development for the rest of the company to a halt. Not a career-enhancing approach if used too often.

3. Send out the changed files in email for people to develop against before you commit them

Pros: Simple

Cons: You may miss some, tedious for people to use. Generally, a bit 20th century.

4. Send out a patch for all the changed files

Pros: less likely to miss files, a bit easier to apply

Cons: harder to send multiple changes as multiple patches

5. Create a private branch, make your changes there, tell people which directories to use the branched version for.

Pros: Easier to continue working on your changes and for other people to accept them when ready

Cons: A bit more work to set up the branch in the first place