This is the first post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this post is shared code base.
You are sometimes asked to work in the same codebase as the customer. This is usually the case for resource consulting, but can be true in projects, too.
In a project, when you share the codebase with external parties, whether it is the customer or other contractors, it is an obvious and substantial risk.
Establish a code baseline, and state clearly in the contract that all changes to the baseline during the project are considered change of scope.
Separate the code being developed from other code: create a branch where you do the development.
Avoid integration at a fixed price. Acceptance tests should be done related to the project code baseline.
Lock the code at the start of the project by creating two branches: one for project development, and one for integration of project code with any new code from the customer.
All merging is done in the integration branch, and no code is merged back to project development. Of course, bug fixes that eases development can be pushed to the project development branch. Other changes that are deemed necessary to incorporate shall generate change requests.
When and how often new customer code is merged is decided together with the customer. However, merging often is recommended.
At the end of the project acceptance tests are done in the project development branch. Once accepted, the project development branch is merged with the integration branch together with the latest customer code. When integration is completed, the integration branch can be merged back to the customer’s default branch.
I was once a member of a project where we worked in the customer’s codebase. We didn’t know at the start that the customer was going to do other development in parallel, in the same branch. Not only that, others merged code into the branch as well.
A lot of issues were hard to track to one particular source. Others were obvious integration issues. Needless to say, the project ended up late with both sides being frustrated.
It would have helped us a lot to set up a baseline and create an additional branch, perhaps offline outside the customer’s version control system.