How can 2 or more developers code a certain feature/module of a software? Let's assume that the module is big and feature rich. How would they prevent each other from overlapping their code? Say, we have the same method but is implemented in a different way. Do you think it might be better to have one focused at a specific feature only?

Is a version control system like Git would help solve the problem? Is it correct that it allows developers to have these "branches" and then merge it later on?

What's your take on this?

  • 3
    Don't forget to communicate and document the state of things. – Lars Viklund May 30 '12 at 15:47

One approach would be to break down the functionality within the module into more than one feature and have the programmers focus on features or sets of features that are as isolated from each other as possible. This can help having too many situations where they step on each others' toes. If there's some parts of common functionality that crosses many boundaries or is used by all other features, you will probably want to do that piece first and any dependent features can try to use local placeholder code to work around the incomplete common functionality, until it's complete.

Having source control will also help. Giving each programmer a separate branch could be a good way to do it, though I've also done this on projects where branches only existed at the project level so we all had to work on the same branch and merge pretty regularly (usually once per day, sometimes more).

  • Assuming that we have finished each isolated feature, how do we combined our finished work into one code file? Copy and paste? :D – Panoy May 30 '12 at 15:34
  • Or that will be up to our chosen VCS like Git? – Panoy May 30 '12 at 15:34
  • 1
    @Panoy: If you have all finished your coding independently, the best way to proceed at this point would be to check into source control one developer's code (it might not matter which), and then have everyone merge those developer's changes to their code, test to make sure nothing's broken, and then check in the next developer's code, have everyone else merge those changes, test to make sure nothing's broken, then check in the next developer's code... This is slow and messy. It's best to have version control at the begining to avoid these long and painful merge-fests. – FrustratedWithFormsDesigner May 30 '12 at 15:37
  • Thank you for the inputs. This site helps me to be enlightened when it comes to practices in software engineering. :D – Panoy May 30 '12 at 15:45

In object oriented programming, there are a number of best practice revolves around high cohesion and the Single Responsibility Principle. The basic idea is that each object should do one-and-only-one thing well.

If you follow this rule, then you run into a lot fewer conflicts. Several implementations of a method? Several Strategy objects containing the varying implementations. Each developer can work on a different strategy--no conflicts. (See the Strategy Pattern for more info on this).

Even if you are not doing OOP, the principle is still a good one. Don't put all your code in one file, but only the code needed to do one thing. Call that code from a master procedure, which one or two developers can own and maintain.

However you do it, you need to maintain good communication between team members. Also, develop a good regression testing process (automated, preferably), so you know when a change is going to break something.


Do one thing and do it well, then document it and make sure your peers understand it well enough to use it. Having two people working on a very localized piece of code is just a waste of developer time and unless your entire module consists of two functions, in which case you are probably doing it wrong anyway, you can always split it up into pieces that can be worked on by individual programmers without interference. It's a simple formula that works and usually deviations from this simple workflow are a sign of a dysfunctional team. That last bit is just my opinion of things as I have observed them on the job.

  • We try to split up the work in different code-parts. For example, one guy can do the webservices, another the GUI.
  • If two people do change the same functions, with a modern source control system like TFS it's not a big problem. It just gives a merge conflict, you call the other programmer to your desk and you solve it together.
  • If you are constantly having merge conflicts one part of your code, it's a bottleneck you have to fix. That means splitting up those classes in smaller ones.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.