I'm programming in Java, in a very OO style, by myself. Never had the chance to work with other programmers (I'm not a professional, at least yet).

Out of curiosity, I wanted to ask: How does working with a team on a project work, especially when working on an OO project?

How does splitting tasks work? How do you develop something that will succesfully work with something another programmer developed? How and when do programmers communicate?



1 Answer 1


Hopefully I can help you a little, or at least point you in the right direction!

As a bit of a disclaimer though, it's a huge topic - and one that I really think takes "getting thrown in" to get a deep understanding of. That said, I'll give a quick run down of the two major issues:

  1. The code and source control
  2. Communications and some tips.

Regarding OOP projects specifically - I honestly can't see too many issues specific to OOP that aren't present elsewhere.

In fact, I think OOP-style programming is incredibly suited to team development. One key ethos of OOP is that I shouldn't know all the details about every object I interact with: I just need to know what it can do, and how I can get it to do that.

The abstractions that OOP can provide are awesome in a team.

Source Control

There needs to be a central place for the project to be stored, and one which allows multiple developers to access the codebase at any one time. This is where systems such as Git (or SVN) come in to play.

I can only speak specifically about Git, as I've never used SVN - however I gather they are similar but with different terminology.

Using Git I can create a repository with all the source code for a given project, and then allow my team to access to the repository. For every feature or bug fix that is then made, individual developers can create their own "branch" which means development can happen on parallel tracks.

Once a feature or fix is completed, it can then be "merged" back in to the main project's codebase. Any "conflicts" can then be detected by Git and resolved at the source level by the developer responsible.

I'm not sure if you'll have used Git before, but it can seem quite complex at first - but thanks to its recent popularity (in part to Github) there is a whole wealth of tutorials and resources out there.

If you haven't used it before, then I recommend signing up to GitHub and getting a feel for it that way! (Alternatively, Bitbucket is a similar alternative, but it allows you to have private repositories for free.)

Git Flow is an excellent Git based work flow that is incredibly useful for teams. Like Git in general, once you work with it for a while it gets difficult to imagine working in a team without it!


Once you get past all the technical barriers, you really come down to the fundamental issue that plagues most projects (technical or not) - and that's communication.

The whole team needs to be aware of who is doing what, when they're doing it and what it affects.

Responsibility needs to be clearly defined

This is obvious, but most projects will use some form of ticketing system - where any feature requests or bugs are logged, and then subsequently assigned to a specific member of staff. (JIRA, Unfuddle etc.) Often these are built in to the source control system which makes life a little simpler. (BitBucket and GitHub both provide issue tracking for Git repositories hosted with them.)

This stops, or helps prevent at least, developers accidentally working on the same issues.

This isn't a complete fix though; you still need to ensure developers are aware about other developers responsibilities. I know in the past that I've fixed other issues that I've stumbled across in the course of fixing a specific bug, purely because it makes sense. ("Well, I'm already here. This could do with a refactor and perhaps I can check for any other issues.") Then I've had to apologise to other developers as they were working on those other issues that I've fixed - wasting both of our time.

In general those, these issues can be fixed by...

Regular meetings

Some project management/development methodologies dictate specific communication methods or meeting intervals. In general, the most productive systems I have seen have been morning stand-up meetings where everyone in a team will give a quick run down of what they're doing - if you limit this to development team members only and have clear guidelines about what to communicate then these can be incredibly effective. I've always tried to stick to:

I am working on X,

To achieve/fix Y,

Which involves modifying/amending Z.

Other team members can immediately take in that "Fergus is working on fixing that bug which was logged the other day, however that means he's working on some code that I need to look at - I'll check with him before I make any changes.".

Architectural meetings

I recently worked with a great team that had a fortnightly "tech chat", where bigger/architectural issues would be discussed. Every member of the team had time to understand the bigger issues facing the project and could discuss potential fixes.

I personally loved this, I didn't contribute much as I was quite new to the project - but being able to listen to the discussions gave me a lot of insight; pretty soon I could understand the project as well as individual thinking styles.

Communication is the one issue that can bring any team down. Technical or not, if people aren't aware of the bigger picture then there is a greater chance that they will fail.

Other issues

It's good to ensure everyone has the same configuration or style when working in a team. What do I mean?


If you're working on a Java project - then perhaps ensuring (for development environments at least, certainly not for testing.) JVM versions are common amongst the team may be a good idea? Then IDEs. It helps majorly if the whole team is using Eclipse or NetBeans or your IDE of choice.

On a web project it might be that all the developers need a specific stack; with specific Apache or PHP versions.

Thinking of factors like this just allow the team to "gel" a bit quicker in my mind.


Tabs vs spaces? CamelCase or spacing_with_underscores? As small as these questions may be when you're working alone, when you're working with a bigger team you really want to strive towards a common style.

In fact, you shouldn't really be able to tell who wrote a specific section of code - you should just know that it belongs.

This is why many open source projects openly publish source code format guidelines/styleguides - for an idea of what these contain, take a look at the Google StyleGuides for their own open source projects.

Tasks and Unit Tests

This isn't limited to teams, but I'm going to quickly touch upon this for one reason in particular: it makes team life a lot easier.

If you have a complex workflow with lots of dependencies, or a long build process - then often it's useful to automate this using a task runner. For web projects GruntJS is awesome, although coming from Java I guess Apache Ant may be quite similar.

As an individual I use GruntJS to build my site before I deploy it to my FTP server - one Grunt command is all I need for my CSS/Sass to be compiled and minified, my assets to be compressed and then my files to be uploaded.

As a team member though, I can use GruntJS to check that I haven't broken any tests - and that I haven't introduced any bugs by not being fully aware about other parts of the project. This is of course, additional to the benefits that it affords me as an individual developer.

I can also use it so that I can clone a project using my fancy source control package (Git) - and run one command to install all my dependencies. This is a big plus, as the time spent getting a new developer in to the position where they can actually begin developing can be quite large - without even considering the time it takes to get used to an unfamiliar codebase.


The best projects I have seen have had documentation (and often quite excessive.) aimed at developers. These kind of documents may explain things like:

1. The development environment:

"We're currently deploying to a server running a LAMP stack, as such developers should be targeting the versions outlined in.."

2. Work flow

"All features are to be developed on a 'feature/*' branch and merged in to the 'testing' branch prior to being considered as release ready."

3. Responsibilities in the team:

"For database issues, talk to Steve. For platform issues, talk to David."

4. A "pipeline" for the future

"When developing new code remember that as of June 2014 we wish to implement x - legacy code may need to be reviewed before this occurs."


It may be worth looking at the work flow of an open source project to get a feel for how it works - whether that be an established one with their own workflow (often heavily documented), or one of the many examples on GitHub.

A final word of warning

If you find yourself working in a team that manages to do all of this right.. you'll hate being anywhere else..! Take it from me, once you've experience a good team then suddenly issues elsewhere can really drag you down. (That's a story for another post however!)

  • 1
    Wow, so much for a quick answer. I suspect another edit may be required to get rid of some of those typos too... Commented Mar 2, 2014 at 15:45
  • Great answer for a question I considered to be too broad for beeing a good one.
    – Doc Brown
    Commented Mar 2, 2014 at 16:39
  • Thanks a lot for the detailed answer :) One question: Would you say that generally, each developer in a team usually works on a piece of code than other developers don't, or rarely look at or modify? For example, in an OO project, imagine a team with 4 developers: Developer A, B, C and D. Is it common for developer A to work on Class X, developer B work on Class Y, and so on - each building the inner implementation of their class, and an interface for this class to communicate with other classes - while other developers do not modify this class' code?
    – Aviv Cohn
    Commented Mar 2, 2014 at 17:05
  • 1
    Thanks @DocBrown! @Prog - That's a very interesting question, and not one I'm entirely sure I can answer! Speaking from experience though, it seems entirely common for that kind of situation to exist at the beginning - or when a feature is being implemented. A developer may take ownership of their new feature (and thus, any new objects implemented) - however, when it gets merged back in to the codebase and maintenance commences it's very much whoever gets assigned a specific bug, hunting down that bug to wherever it actually lives! Commented Mar 2, 2014 at 17:40
  • 1
    @Prog: That depends on the culture within the team and the company. In very large projects, you will see multiple teams working on it and each team is responsible for a specific set of modules. This concept of 'ownership' can also be applied within a team, but it is also possible that all team members work on all the code. Both have their advantages and disadvantages. Commented Mar 2, 2014 at 18:50

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