Guide For Small Team Programming?

dm writes "I run a small design shop and have been doing more and more web development, including fairly involved back-end programming of what's now essentially become our own CMS. Up to now I've been doing all the programming myself. Now we are working with a second programmer for the first time. I already use version control (SVN) and an issue-tracking system, and I guess we are both decent at what we do — although self-taught, but we both lack experience programming in a team context. Is there a useful guide for this? Most of the tutorials I have seen for Subversion are surprisingly organized from a single coder's perspective. Where else should I look?"

Comments

Talk to each other

[erikharrison]

There are lots of things I could throw out, sure, but most of them came from principle numero uno - talk to each other. Learn each other's strengths and weaknesses, learn how each other works, learn when a process isn't working for one of you, and learn to evaluate each other's code. Process is really about leveraging communication to improve the product. So start building that communication.

Re:Talk to each other

[zappepcs]

Wow, there are probably a few posts going to be about some program that a user loves, but this one is perfect. I've worked the last 8 years in an environment with two coders and 5 managers. What worked for us is exactly what this guy suggested and we did that in spite of what the managers wanted. We developed a perl/cgi template that all the code worked under and it worked so that either of us could look at any of the code and work with it, sharing routines and snippets. Now I'm in charge of maintaining all of it, and it's more or less like I wrote it originally. No matter what programs or coding styles are sold to you, the ONLY thing that will work is what works for the two of you and that will probably not fit into some white paper. Just find what works for you by talking and analyzing what each of you are good at. When you find it, write a paper and go on the talk circuit.

Re:Move to CVS

[StrawberryFrog]

For the love of Dog, please don't move from SVN to CVS.

SVN was designed as a "compelling replacement" for CVS. And it succeeds.

I've yet to see a compelling reason to move to SVN.

That doesn't mean that there's a reason to move back. If you don't see the benefits of atomic commits, keeping version history over file moves an renames, and rapid branching then by all means, stay with your CVS. Just don't drag other people back down with you.

If nothing else, CVS is pretty much a dead end. The next version of CVS is SVN. SVN has a development roadmap, CVS has migration-to-svn utilities.

My tips

[dubl-u]

Here's what I'd suggest:

• Work together - Sit near one another, within easy conversational distance.
• Integrate frequently - Update and check in every few hours.
• Write tests - Good nit and acceptance tests are documentation that a computer can verify. Make the computer do the work of making sure the other guy hasn't broken anything.
• Use a continuous integration server - A CI server will wake up on every checkin and run all the tests. That way you discover problems early, when they're easiest to fix.
• Work out common standards - Every time you notice a difference in style, have a nice chat about it. Eventually you shouldn't be able to tell who wrote what.
• Release early and often - The best way to do something well is to do it often. Even if it's an internal or beta release, the more often you guys ship, the smoother working together will be.

I hope that helps!

Re:Move to CVS

[StrawberryFrog]

Because of this one point of difference I still don't believe SVN is a mature product.

I don't think it's because the SVN team are incompetent or haven't finished the basic feature set yet and their product is "immature".

It's about priorities - Oddly enough, the SVN developer team and community don't seem to have prioritised the feature of a revision-tracking system totally losing track of a revision. Priorities, as in "that's very far down on most people's list of priorities".

Re:Move to CVS

[Cyberax]

There's svndumpfilter - it can completely obliterate selected files. A complete dump/load cycle requires a bit of time, though.

See: http://subversion.tigris.org/issues/show_bug.cgi?id=516

Frankly, that's a pretty stupid reason to chose CVS over SVN.

Re:For the love of god - DON'T!

[hattig]

Only if you're some freaky self-motivated person.

Otherwise you'll surf the web all day after getting up at 1pm and watching Daytime TV for a few hours.

Two people will motivate each other. Three people might even get the time to do other business essential things, like the accounts! Also nicer for pub lunches, two people is a bit one-on-one.

More than three and I think that you start getting communications issues, unless you are all working on very different projects rather than the same codebase. Once you're in the meeting room, with the projector, and the Wii, you'll end up playing Mario Kart, which kills productivity. Also there's enough people to not have the focus on your own work, so you'll surf the web unless you're self-motivated enough or have a deadline.

Re:Move to CVS

[Jack9]

How about the backing storage? If shit happens, I'd rather try to recover from text files than binary chunks

You are correct that a text-storage would make recovery easier, although I have doubts that it's at all possible to recover from the Berkley DB in most cases. My question is what kind of failure partially damages a repository that you want to recover whatever part of it you can? I assume a hardware failure. SVN stores text files, binary files, directories. A text recovery for these things would never really be possible anyways. The only way to recover such data would be from a backup regardless of the version control method. SVN is backed up by simply zipping the directory and putting a copy somewhere. I do this daily & weekly. This is how recovery is usually done which is indifferent to filetype. This same approach is done with CVS but causes some serious issues when trying to get everyone back on a restored copy.

Why would we want granular access to text files in storage? If 'recovery' is high enough on the list to warrant "the primary reason", your revision control needs to have access to the backend storage, the system must have a high failure rate and I would tag it unreliable. I don't know of a reason to want access to the backend storage directly. If SVN were somehow aberrant in this regard, I would admit it, but there are lots of utilities that do not have flatfile backends and it only seems to be an issue with revision control. Sourcesafe, GIT/Bazaar with its hashed key/values or god forbid its crypto hashes, means you can't access their files directly either. Is it really assumed to be a good thing?

I believe the point of version control is to track all changes, regardless of intent (bad commits count). This does not speak to anything else including recoverability method. I find it mildly disturbing that you can or would alter the history in CVS. In SVN you basically have to dump the entire repository history to make a change to the history. The number of times I've had to restore an SVN backup is 1. That was to do a test of the integrity of the zipped repository over the last 3 years, 12 repositories and near 10000 commits. SVN is stable enough for me.

In the case where you want or need the peace of mind to be able to alter the "backend storage", I hope you have a long and prosperous career with CVS. We just have different goals.

Re:What I require for my team

[thegrassyknowl]

1. Standardized IDE. Everyone use the same thing and you will be able to do builds, deployments, and fix bugs quicker. Eclipse/Zend/VC++ whatever.

That is the dumbest thing I have ever heard. Horses for courses. I was an Emacs guy until recently when I switched to Vim. We have a couple of other Vim people and an Eclipse guy here. Everyone gets by using whatever 'IDE' that they want. The IDE does nothing except provide them an editor. Forcing the same IDE on everyone is asking for reduced productivity.

Standardized build and deployment. ANT/Bash scripts/whatever

With this you don't need an IDE preference. We have Makefiles and Ruby scripts that do everything we need. SCM actions are mangled into scripts so branching, merging, etc are all handled and the right comments (according to our policy) are inserted into the repository. Releasing to production and staging servers is handled and everything works neatly.

If you get this part right you won't have the headache of forcing a GUI guy to edit code on the console and you won't have the loss of productivity when you get a console guy to try and use a graphical (read: crap) IDE.