I work on several projects, both for work and for recreation, that require code editing by more than one person at a time. Some projects I've created on my own, while others were well established long before I came upon them. There are common threads between them, and I would like to try to point out some things that I've learned along the way.

When working collaboratively, a source code control system is mandatory. There is simply no other way in my mind to efficiently collaborate on a project of any size without source code management.

One might think that code control is not necessary for collaborating on small projects, but for those smaller projects it is especially true. If a project consists of a single file, and two people are working on that file, the only way to make the changes not continuously conflict with one another is to use some form of code control. The alternative of sending back and forth changes or keeping in constant contact to ask if another person is editing a file you need is not practical.

Source control does not consist of having a single copy of the source on a development server that everyone edits directly, and checks in and out. Using source control this way would be tantamount to creating periodic archives of source code. The intent of source control is to allow collaborative development, by giving developers the option to create their own development copies of a project so that they can edit what they need without interfering with other developers' work. When discrete working parts are completed, the code management functions serve to merge the changes back into the main copy, from which the project can be deployed.

It is an essential part of source control to have a working copy for each developer so that changes within each do not interfere with other developers' work. As I said, it's useless for everyone to work out of the same working copy, because none of the benefits of source control are realized that way. There is little accountability, and the protection of files from overwriting due to simultaneous editing is non-existent.

There are also additional benefits to a developer-specific working copy. If the copy is local, then the developer need not be connected to the server to work and make edits. By editing on a running local copy, changes can be seen immediately. Also, runtime debuggers are difficult to configure properly on remote sites, especially if that server belongs to a client or is using shared hosting. With a local copy, a developer can run a runtime debugger when the need arises, and configure the settings of the local server to accommodate this at whim. Developers are also free to test server configurations that they would not be able to test on a shared development server, which would affect the other developers on that server. They can then troubleshoot server parameters locally, and use their findings to adjust the shared server at a time that is convenient to all working developers and server admins.

Another benefit of the working copy process is that developers will be required to update their own working copies with the changes of other developers to keep in sync with the core project copy. This provides an ideal opportunity to review the changes committed by others, since the system will often show what files were changed, and even what changes were made in each file. If working on a shared development server, it's nearly impossible to know what part of a file has changed to be able to review it, making peer review similarly impossible. Source code management provides this opportunity by default.

Since any project could become collaborative at any time, it is also best to configure all projects to work well with source control. This means, among other things, that projects should centralize their configuration options, and not rely on the server system for storage of those options. For example, developers will connect their working copy's code to its own database while working. To do this, the configuration options for connecting to the database should be in a single file that is not included in source control. This makes it easy for developers to commit changes without mangling the staging server's database connection.

Similarly, relying on environment variables that are not going to be present on every development system is problematic. Since not every developer has access to the exact development platform on which the end product may be employed, it's important to set baselines when the project begins. If the target platform must be specific because of tools employed there, then that should be specified. For the most part though, even projects on Linux are reasonably portable to Windows.

It's very possible to create a project (for the web) that runs smoothly on Linux, Windows, and OSX with any small OS-specific changes isolated to files that would not be in source control anyway (like the configuration). It takes only a bit of planning to make sure that a project will run in all places, and after you've figured it out once, it's easy to use the process for any project.

By assuming any new project will enter source control as a best practice, you can make your projects easier for others to work on, speed development and delivery time, and leverage the benefits of source control revision tracking.

My Home Owner's Association has a web site that's pretty sparse. I thought that I would take a bit of time to create a new site for them using Drupal, and increase my Drupal skills. There's nothing like throwing yourself into the fire to get out of the comfort of the frying pan, you know? So I was thinking about some features that I might like as a home member of the association, and how I might accomplish them with Drupal.

The first thing I'm going to want to do is get a theme that pleases by aesthetic sensibilities. It's not that the Drupal themes are ugly per se, but they all seem to offer the content in the same way - with the admin stuff exposed for anyone to see. I think that I want the full administrative side of the site to look different than the typical member-facing side. Rather than providing all of the functionality of Drupal the way Drupal does, I would like to select specifically what features appear on the site, and display them in an appealing fashion.

There are some features that I would like to offer. I think that a message board is important for our community. If people could post events to the board and others were subscribed to it, we could all be aware of things in the community that were of interest to us. Having a kind of "classified" section would be nice, too. People could sell items to other people in the community, and offer services, like babysitting. (Oh, that would be fantastic.) It would be extra interesting if you could subscribe to only those channels of interest that you wanted, so then I could eliminate from my feeds things like Historic Yellow Springs events, in which I have no interest.

It would be nice if we had a good event calendar. We could keep track of things like when construction is due and when the nearly-monthly lawn treatment is set to happen. There are some people in the development that take care of the plants around the entrances in the common areas. With a calendar, we would have an idea of when they are active so that other people could help.

Posting photos of events in the community could be useful, but I don't know of many things that have happened that would have photos. The one even on the existing site is for cleaning up part of the walking trail, an event that you wouldn't even have known was taking place if not for word of mouth. See? We need a calendar.

The site would need to have association information. This includes phone numbers for all of the companies with whom we have service contracts would be great - trash, recycling, sewage, landscape, snow removal, etc. Today I noticed that once again the mower people were laying around all day, with their parked trucks blocking a lane in the main through-way, then suddenly started mowing around 4:45pm before everyone started coming home. Not that I mind seeing topless Mexican men laying in the common areas with hats over their faces, but... No, wait, I do.

There should also be web-based forms for requests common in the association, for things like outside maintenance or requests for pools. The site could keep a record of the requests and the request documents, which could be uploaded as PDF or TIFF and referenced as-needed. But for common applications, a web form would be great - allowing more flexible use of property in a more timely manner. We're already using the site for board elections, so I think this is a natural step to take.

Minutes from the association board meetings could be published in a timely manner. It bugs me that I have to wait until the next meeting for the board to approve minutes from last month. Without attending the meetings, I have no way to know if I should act. What should happen is the minutes should be compiled by the secretary, then published to the web privately for the board to approve electronically. When the minutes are approved, which could be two days after the board meeting, the system would put them online for viewing by the association members.

It might be neat to have a map of the development in flash. Show the homes that have registered users in a different color. Let you measure distances on the walking trail.

There are a lot of good directions to take the site, and the existing site is pretty lackluster. I think it needs some love. I'll have to see what I can come up with.