> I wrote something about this a while back, although it was aimed at the
> other end of the market - high turnover, small projects. Some of the
> suggestions may still apply though.
Two great articles - I enjoyed reading them!
In response to the question of how do you manage with teams, I have two
things to add:
1. Version Control - I am surprised I haven't seen more of this. We do
lots and lots of projects for smaller customers, and it became
impossible to try to remember the details of them all. Also, customers
would ask for changes, and then after everything was live would ask for
roll-backs of some of the changes ("we want this, no we dont, we want
this, no we dont..."). We solved the problem with Subversion
(http://subversion.tigris.org/), an open-source version control system.
We now have a history of everything that was done for a client, and it's
easy to roll things back. At first it seemed like overkill, but now I
can't imagine working without it.
2. Documentation - As was mentioned in the framework and modular
articles, we use the same foundations again and again, so we document
those to a 'fair thee well'. I saw a post yesterday on a list asking
what /*\*/ meant in a stylesheet. Those are the types of questions we
want to avoid in our own code, so in addition to the base documentation
(which is extensive but only had to be done once) we document anything
non-intuitive we do for a customer. That way we don't have to spend
hours trying to figure out why we did what we did when the stylesheet
has to be re-visited by a different team member months later. If you
have ever had to work your way through the "cascade of broken layout"
because you forgot why you did something in a stylesheet, you will know
what I'm talking about. These documented stylesheets go into Subversion.
We then run a little script that strips out all the comments before upload.
P.S. Another tip, hopefully not too off-topic - we have several colleges
and junior colleges in the area, and all are looking for internships for
their webdev students. One of the projects interns have really liked (in
addition to the sexier stuff) is documenting a stylesheet. It's a win
for them, because they get to dig into the code and really understand
how it works - usually sitting with a browser and editing css sheets to
see cause and effect - and it's a win for me because I get to coach
rather than write. If you enjoy mentoring and are willing to invest a
little time to make this a positive educational experience, you will
find it to be a great project for interns.
I am sure there are more elegant ways to accomplish each of the above,
but these have worked for us. Hope it helps in your project.
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/