Name:

Integrate Early but don't Integrate All the time

Description:

The situation where I saw this pattern involved a solution which had 2 systems with BizTalk in the middle.  The developers then hooked together the solutions on each of their machines so that when one of them wrote a little code he would need the component on each of the other 2 developers machines to be able to run his test.  This would work okay until one of them added a breaking change and the others would not be able to do anything until everyone was working again.

The main point on this anti pattern is it is good to integrate early.  So for example if you have a feature which is ready you could make it available for the others to use by in BizTalk's case publishing your application to a server where the others could hook up to it if they wanted.  Integrating Early can often find problems and is a good thing.  However integrating all of the time is a bad thing because you create strong dependencies on other teams and other people.  For example if Developer 1 goes home early and turns off his machine then Developer 2 can not do any work.

Symptoms:

1. You can spot this when you see developers having to work together when they are on separate teams to get an end to end solution working but they are no where near the end of the development phase.
2. The individual developers will not be able to run their tests or demonstrate their code without the other developers code working

 

Pain:

1. Dependencies - This will create strong dependencies between teams which can cause conflicts of interest.  For example if Developer 1's team decided his component was low priority and reassigned him for 6 weeks to something else then Developer 2 would not be able to progress his work.
2. Testing - Each developer can not unit test his code in isolation.
3. Deadlines - Deadlines are risked because the developers often end up having to help solve each others problems rather than focusing on getting their own work right.

 

Cure:

1. Contract First Development - The contract should be agreed between each developer on how they will communicate and what that will look like, but then each developer should create a stub of each of the systems they will communicate with.  This is easily done for some systems such as systems which have a web service façade.  You can agree the contract using wsdl and then the consumer of the service can use wsdl.exe with the /Server switch to generate a stub of the code which the service provider will have.  It takes little time to create a stub but doing so means the developers on each team can do much more testing on their own and can run their solutions in full against these stubs.  As result of this the developers can progress with their work much faster as they can amend the stub to provide the responses which suit their own testing conditions rather than having to worry about the complexity the real system they would communicate with.
2. Define set periods where the teams will actually hook up their code together to test.  This will ensure it is done in an organised, efficient and well communicated way.

Comments: