Jul

Managing development

As I’ve mentioned in a previous post, we are developing the Webtogs site from scratch, using our own development team. Our 2 primary php/ajax/mysql developers are based in London, and our office is in Dorset, so it’s a remote relationship. As the world becomes a smaller place, more and more companies are out-sourcing development work to other countries or domestic locations. With this in mind, I thought it might be interesting to take a look at how we manage this.

We’ve all worked together for some years, so the concerns over trust and that kind of thing are long since dealt with, but remain core concerns for companies looking to establish new working relationships. What I’m talking about here, is communicating the design and features to a group of remote developers, who, bless them, have to then make it all work!

All the XHTML & CSS is done by developers in Dorset, whilst the core code (ajax, msql, etc) is written in London. Our work flow, at a simple level (and on a good day!), goes something like this:

We also use Basecamp, from 37 Signals. I think this is a brilliant bit of kit. I’m not going to bang on about it for long here, as it’s been well covered on many blogs in the past. We tend to use it for milestones, messages and as a file repository for specification type documents. Any large files we need to share are uploaded to our servers in London, saving on storage space with the Basecamp system (there’s a limit).

Here’s a screen shot of our To-Do page, early in the development of Webtogs…

In addition to this, we also use Skype, as, I suspect, does the rest of the world! The file sharing tool on Skype, in particular, is a great feature.

Any changes to css, etc can be made locally from Dorset. We have SVN running on our development server, so if there’s a catastrophic overwrite, we can roll back a version with little hassle. (hasn’t happened yet, mind!)

We try to document as much as we can, and we use change request graphics, with the date in the filename to convey more complex changes. We’ve found this so much easier, than trying to explain in text what’s needed.

A recent change request graphic, for the config palette on the large product view…

At the end of every week, we delete all the completed change request graphics, as in the past, it’s become a total mess, file wise, for larger projects.