If two developers are working on code that has dependencies, should they work on the same feature branch?

Question

In our current workflow, developers always create a new branch off of develop, work independently, push their changes to the remote development branch. Sometimes the work of one developer has a dependency on the work of another. In this situation, the developer whose work depends on the other will merge the feature branch with the needed code into their own, and develop against that. In an ideal world, they will remember to frequently pull from the other feature branch. The flow looks like this:

However, since the world is not ideal, sometimes we'll wind up with merge conflicts going into a release because the developers will have different versions of the dependent code in their branches, or worse there might be some "zombie code" laying around their branch. I'm thinking of proposing that in these situations where the work of one developer has a dependency on another, that we should treat the work as a single feature, and both devs should work off of the same branch, like this:

However, I'm wondering if this is "best practice" or if it really confers a benefit as I think it does. How do others deal with this situation?

Answer 1

This is how we managed these cases in our company:

• The designated developers called the architect / tech lead
• Together they first plan on a whiteboard the general solution, algorithms and domain separation
• Then they do pair programming and sometimes even mob programming to put in place the "common" part of the code.

Most of the times these will be interfaces / abstract classes / swagger etc (there is a reason we also call interfaces 'contracts').

Once the interfaces and the common code has been developed it can be pushed to a branch feat/feature_name or release/v1.2.3 and then each developer can pull a branch from it and use mocking/stubbing strategies to advance on their side without actually having their partner's code ready. This is one of the most essential concepts of programming - abstraction, decoupling and cohesion.

Once finished - your merge back to the common feat branch and then your colleague can rebase to test the integration.

Speaking of integration - integration tests are really helpful in these situations.

PS: All of this is valid for a single feature team. If you have different feature teams and you have dependencies between the teams there are whole chapters in Eric Evans' DDD blue book on how to tackle it.

Hope this helps. Best Regards Alexander