My friend and I decided to create a large programming project together. Before that, I have never worked in a pair (I had quite many projects on my own and at work the boss defined the task for me). But now we have an idea of what kind of app we are going to do, how to plan it...but how can we divide the responsibility for the code in the project so that we don't do each other's work and it is not so closely related that we have to overlap each other's code?

How would you divide the tasks, what is the original way to do that? How would you divide the tasks in modules if they represent one application and are very closely related?

This is an enormous question which whole books have been written on - how large? If you've only got two people it might not be feasible. Separate modules as much as possible with clearly defined interfaces will be the easiest initial way but ensuring integration works as expected early will be essential.
– MichaelMay 9 '13 at 12:17

You might want to have a look at Plastic SCM for source control.
– HABOMay 9 '13 at 13:17

If using eclipse, for a simple task setup look at mylyn. Are you using any specific environment (I find the perforce 20 user trial for source code and combined with eclipse mylyn hooked up to perforce jobs to be a very nice arrangement for a small team).
– user40980May 9 '13 at 14:53

I can confirm that having a good DVCS with merge tracking support for getting your work and your partner's work to merge up is critical. Git, Mercurial, and Plastic SCM are all fine. Subversion is borderline unacceptable, and everything else out there is pretty much rubbish.
– Warren PJun 11 '13 at 22:24

3 Answers
3

First of all, you need some sort of source code control. My company uses Team Foundation Server, but there is some free software out there (don't know which one is the best, so I can't recommend). Then, you need to have some sort of shared task list, so you can keep track of what's to be done and who's done what. There are some sites for that also, but I haven't tried them out.
Having said that, the organization of modules is entirely up to you. I'd like to stress out that you really must plan the project, that is, to write some sort of technical specification, or at least have user stories. If there are some common methods (for example, converting a DateTime into a string), you have to know who's writing it, and who's editing it...

Really, there is not golden rule to apply, especially if you are not implementing through a methodology (scrum, kanban). Just apply common sense.

First of all, use some kind of project management or bug tracking tool for your tasks. (e.g. Trello, Redmine etc.). That way you could see open tasks and the tasks you are working on. If you decide you need to add more people on the project, they can easily see all the tasks.

Dividing the tasks is the hard part. But some logical way is to separate the tasks to e.g. design of user interface, client / server side programming, database etc. So you can work on design / UI, while your friend builds database and back end; or you can build some things together and other modules separately. You can choose to build some part of the system because you know how to do it, or you can choose to build it because it's fun and you want to learn something new.

If that's your personal project you have all the freedom to do what you want and how you want it.

In my experience, it's usually no more difficult than making a list of everything that needs to get done, then each team member picking something off the list. If you both feel that the same task must be done first, then either work together or break it down further. If you estimate a task to take longer than 20 hours or so, it's probably too big, so break it down.

As other answers have mentioned, you need source control and a central place to keep your task list. I would recommend putting both in one place. Services like Bitbucket or GitHub are excellent for that sort of thing.