What must be done to allow a development team to minimize difficulties as new team members are added?

Question

I work at a small Web Dev firm, and have been handling all the PHP/MySQL/etc. for a while. I'm looking at improving our practices to allow for easier collaboration as we grow. Some things I have in mind are:

• Implementing a versioning system (source control)
• Coding standards for the team (unless mandated by a certain framework, etc.)
• Enforcing a common directory structure for our Desktops (for backup purposes, etc.)
• Web-based task/project/time/file/password/contact management and collaboration app(we've tried a bunch; I may just create one)

What do more experienced developers view as necessary first steps in this area? Do you recommend any books? One thing to consider is that the bulk of our daily tasks involve maintenance and adding minor functionality rather than new projects, and the team size will be between 3 and 5.

I just found a related question about teams that will be expanding from a solo developer.

Answer 1

• Implementing a versioning system

If this means source control and you're not doing it, then do it NOW. Don't wait, don't even finish reading this. Do it. If you mean coming up with some fancy pants scheme for numbering your releases then simple is best. Try this...

X.00 = major release that may break compatibility or you want to charge money for.

0.X0 = new features that don't break things. Free update.

0.0X = bug fixes.

• Coding standards for the team (unless mandated by a certain framework, etc.)

Again, keep it simple. One A4 page is more than enough.

• Enforcing a common directory structure for our Desktops (for backup purposes, etc.)

Your source control system will do this for you. When a dev does a check out they will get the directory structure. Your VCS is a backup, just make sure you backup the machine with the VCS on it. Anything not in VCS isn't important and doesn't need backing up.

• Web-based task/project/time/file/password/contact management and collaboration app(we've tried a bunch; I may just create one)

Don't waste your time building one. The free tools on the net are good enough.

In addition you want...

• a continuous integration system. When a dev checks something in they need to know that they haven't broken anything, ie. it builds in a clean environment, they haven't forgotten to add new dependencies, run tests to show they haven't caused a regression, the system deploys to a clean environment.
• a deployment system that includes roll back. You should be able to deploy a new system or push an update with a single command and back out a broken version just as simply.

Answer 2

I think the big thing you've missed there (as the majority of your time is spent maintaining) are unit tests. Since maintenance by default requires modifying existing code, Unit Tests will help you to effectively determine whether or not those changes break anything else.

The other thing I don't see in there is an issue tracking system. Once again, if you're doing a lot of maintenance work, then a good issue tracking system is imperative (though, you may already have either of these, and you just didn't mention them).

Answer 3

In my previous webdev job, we were 5 devs working.

• We've succesfully used redmine issue tracking software to maintain and create new projects, it supported subversion and mercurial as version control system (VCS); in tandem. So projects were not prohibited to use different VCS than the rest. The only thing that matters is that you keep track of your issue numbers and redmine does the rest.

• Coding standards grows out of necessity. When the team starts to have merge conflicts, they tend to set standards among themselves to avoid the conflicts. It's a good learning experience.

I'm puzzled with the common directory structure thing. Web devs usually are good at wiping their computers clean and set up the computer quickly again. If you have problems setting up the computer again, you really should version control the web configurations so your projects are already set up when you check out the code.