I'm currently working in a very small team of programmers (2-3) and I'm looking for advices/best practices on how to organise our work. We're all working on the same application using PHP. Today we're kind of all working on our way.

Today situation:

  • List item that have to be worked on by each dev 1/week. What has to be done is defined at a high functional level (ex: Build the search engine for this product..)
  • Commit / merge our individual branches (git) every week before the next meeting
  • No real dev rules, no code review
  • No test written (aouutch)

Problems faced:

  • Code quality issue: discovering someone else code is sometime tough (inline, variable+function+class names, spaces, comments..)
  • Changes in already existing classes (impact on someone else work)
  • Responsibility of each dev unclear: after getting someone else code
    and discover something messy, should I make the change? Should he
    make the change? How to plan those things,...

What I'm looking for:

Basically I'm looking into structuring the way we develop things in order to avoid frustration and improve overall quality.

  • How to define coding standards (naming convention, code rules...)? Do you you any validation script to make sure code is valid before committing?
  • Do you think that defining an architect role in the team is needed? Someone that would actually define what has to be developed during the next phase. By defining interfaces or class descriptions that have to be written. (Does it make sense in such a small team?)

Today we're losing time into understanding what others did or tried to do, we're also losing time in discussion like "you should have done it that way! Why is this class doing that and not that..? Shouldn't we have a embedded class rather that this set of data...".

I'm looking into a work process, maybe with more defined responsibilities and process in order to improve our performance. If you have experience, advices, best practices or anything to share that we could benefit from it will be much appreciated!

Thanks a lot for your time!


For a small team you probably don't need to focus too closely on the type of rigid process that larger teams go through, however there are some low hanging fruit here that can really help.

Daily Stand-Up

A simple stand-up at the start of each day, where everyone just briefly explains what they did yesterday, what they are going to do today and raises anything that is blocking them from making progress.

Coding Standards

Most languages have a standard or a few standards available. The important thing is not which one you choose but that you choose one. Then everyone gets to stick with it, no exceptions.


Before you begin on a "build the search engine for this product" type project, you need to put together a functional specification for that search engine. This will describe in clear terms how the system will work without going into too much implementational detail. The document must be completed and the team must have reviewed it before coding begins. That would probably be enough architectural oversight assuming everyone in the team is at a reasonable level as a developer. These specifications can also then be used as the basis for future documentation to pass on to users or as reference material when revisiting older work.

Code Review

Nobody's code gets merged into the master branch for any project until it has been reviewed by at least one other team member. Code that does not meet the coding standard doesn't go in, code that is undocumented doesn't go in. This will save a lot of problems later on and, combined with the coding standards above, you should end up with much more readable code.

You could also take it in turn to pick examples of code from time to time to share on CodeReview.se - that would give everyone in the team a chance to learn from the wider experience of other developers and help to encourage good coding from everyone.


Nobody performs functional test on their own features. You have to get someone else to test for you.

Also, no code is complete until it has unit tests and those unit tests pass. Unit tests are part of your build process and if they fail, the build fails.

Merge early, merge often

If you are doing weekly merges and having collisions between developers then you might need to look at your branching strategy- if something is going to have a knock-on effect for other developers then it needs to be merged in as soon as possible so that everyone can use the new version. This is a matter of prioritisation and will make everyone's lives easier.

One of the biggest advantages of a small team is that you are a small team. Everyone can easily tell everyone else what they are up to and ask everyone else's advice. Many of the suggestions I'm making here are really just ways of facilitating communication and that should be way easier in a small team than in a big one.

| improve this answer | |
  • Thanks for those advices. We did some daily stand-up but dropped the habit we definitly should go back to this. Everything else is things we know we have to do but never take the time to put them in place. Code review is something new to me, but definitely make sense. Thanks for the hints! – LEM01 Oct 28 '13 at 13:58
  • At first you have to be really strict about rules like this- everyone has to follow them always. Once they turn into habits, it becomes a bit less important because people will do the right thing without having to think about it so much. Discipline is really important in these cases. – glenatron Oct 28 '13 at 14:16

I completely agree with the other answer on the importance of code reviews and daily-standups.

Architect Role

This is a tough one. I guess it would depend on the experience of the developers on your team. In a team your size the more experienced the developer the less you need an architect. I would suggest more pair programming and mentoring of less experienced developers before adding an architect.

Business Analyst

If you are going to add a person to the team I would highly recommend adding a competent business analyst who can write agile style requirements/stories very well. I have found that in the long run having someone who can properly define the business needs and write requirements/stories that can be easily tested against can be more valuable to the end product.

Coding Standards

Using a tool that warns you when your not following the accepted standards is a good starting point. Everyone has to use the accepted format.

Regular Code Review Lunches

One team I was on was in a similar situation. We instituted weekly lunches where everyone brought their own lunch in and met in a conference room and one person on the team presented a piece of code or functionality that they wanted to discuss. They would do a quick presentation of the code and then we would talk about different aspects of it.

Baby steps

Go slow with any changes you make. Doing it all at once will only upset the balance that your team already has. Create a long term plan for where you want to take the team and share it with them. Choose one step at a time and focus on it until the team has accepted and integrated it into their workflow. Then move on to the next one.

Don't step on toes

If you are not the teams manager than sit down with him/her and present your goals for the team and suggest how things could be changed. If you are the manager make sure that you respect the position each team member holds. Any changes made will upset the balance that already exists and you don't want people leaving because someone was excluded from the process when they really should have been included.

| improve this answer | |

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