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

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.

Answer 4

Chat is Awesome

All you really need to collaborate, IMO, is anything with chat and file transfer and something like Google docs for issue tracking. I've found Skype to be among the most useful tools at every company I've worked at that adopted it.

Chat is invaluable because it lets you inform people of issues or concerns that aren't immediately blocks without having to wait around and wait for them to finish off another conversation, etc. and it tends to get a more immediate look than e-mail.

Also, the one thing I like about Scrum-like processes is the daily standup, except just chat it at roughly the same time of day. No meeting room waits. It's easier for people to work at home when sick or waiting on the cable guy or whatever... And it's valuable to have that written record so you can document frequently recurring issues when you see the same things coming up over and over again. Create a different room for that daily check-in so it's kept clear of all the other day to day details that tend to pop up in chat.

Training on Tools/Legacy Code

I've never seen more time wasted on anything else. If you have a tool somebody is unfamiliar with, familiarize them with it. Hand them a good book. Have them sit down with you for occasional debug sessions on an IDE, etc... Likewise with code that you're maintaining or re-using a lot. Make a point of documenting it as you introduce new devs to it and they ask questions, etc. but definitely sit down with people and talk about legacy code before throwing them at it and give them plenty of debug tasks early on so they can dig into a bit more before adding features or re-using portions of it.

Whatever You Choose For Documention, Stick With It

Keeping docs all in one place, written with the same tool, and accessed the same way is huge. You're not doing anybody in the future a favor letting people just doc however, wherever, with whatever they want.

Have the Entire Team Do Estimates for related projects

It is hugely valuable for rookies to get more experienced opinions and ultimately helps everybody get better at it.

Nip Configuration Issues in the Bud

I've been in scenarios where it could take days to configure a new machine. There's no excuse for that. Get all essential tools and pre-configured servers on one build/ghost image keep it up to date as new stuff is added. Don't assume devs can just handle installing their own stuff. It's easy to forget just how many layers of stuff you've added over the years.

Use Version Control Properly

Some of the afore-mentioned configuration issues I've run into were in large part due to another team not feeling comfortable with branching, forcing us to redo about 30 XML config files by hand (that should have never happened either of course) once a month or so whenever we updated a version of the app we maintained. If you're not yet a VCS power-user, become one or hire one. Also don't let Maven, Ant, and an outdated version of Eclipse get into a 15+ XML file fight with each other. It's real ugly.

Update to Latest Versions of Tools/Frameworks/Librabries Whenever Possible

You never know when stuff is going to go out of date and suddenly a new dev has to track down something not available anymore. Stuff like that can also clobber ramp-up time, although usually this issue will be dealt by creating images of everything you need. Another issue you'll dodge is being forced to handle a series of upgrades all in one shot.