On Multiple Projects

2 Comments

If you’ve ever been a contractor you too have faced the juggling act that is having many different projects in the air.  There is quite a bit of work that goes in to just managing those projects, much less actually doing the work on them.  I’m going to write a bit about how I handle them and manage to keep a semblance of sanity.  Right now I’m looking at my “in progress” list and I’ve got 10 projects open at various stages of completion.

Organization

One of the big problems with having so many projects going at once is that there is just no way that you can remember where you were with each project.  There are a ton of great online tools that I would recommend for keeping everything organized.

Before you start signing up for every organizational tool out there though, I would impart a tale of woe on you.  Starting a large project Powered By Geek wanted to make sure we crossed all the T’s and dotted all the I’s so we set out to use just about every organizational tool out there.  We had Basecamp, Campfire, Lighthouse, a Wiki, a large chunk of API documentation, Google Docs, and many more.  We actually had everything in a proper and logical place, however the organizational scheme that we used backfired.  Trying to get into the swing of a project and having to open up 10 different tabs and login to 10 different tools soon ended up with people getting lazy (I happened to be the laziest of them all) and just throwing documentation together into other tools, trying to consolidate it so I didn’t have to track it across other tools.  Things quickly got out of sync, and confusion starting happening between developers.  However once we had pared down the list of apps to just a few major ones and kept information in less places things started to move a lot smoother.  The moral of the story is to try to organize stuff as well as you can within a few tools that you are comfortable with, and then slowly integrate other tools if there is a need for them.

My MUST HAVE tools are really rather simple.  You need ticket tracking, milestone tracking, repository tracking, a place to write messages and warnings, and finally if you have more than two people a place where you can all get together and talk about the project(s).

Ticket Tracking, Milestone Tracking, and Notice/Messages

Lighthouse is a great tool and manages to fairly simply cover most of the needs of a small contracting house.  The ticket tracking is fairly easy to use (simple enough that you could give a client access and have them report the errors/changes themselves) and is also pretty customizable.  It also allows for milestones to be created and tickets assigned to them which makes it somewhat easy to see a break down of milestones and how far along you are on them.  Its message system is decent (I’ve been using it to write standards and code guidelines), I wish it stood out more but as long as people know to check it then it is useful.  Lighthouse only really does the ticket system well, the rest of the items it does just good enough that it makes sense to use the features rather than bring another tool into the mix, but it is fairly inexpensive.  The ticketing system does lack some somewhat standard features though such as parent/child ticketing and time tracking, but you learn to live without them (or in the case of time tracking you learn to just keep track of it somewhere else).  Since most of PBG’s projects are done on a task/goal basis the time tracking wasn’t that big of a deal for me.

Code Repository

As of right now, there is no better choice for a code repository than Github.  If you are managing multiple projects then I don’t think it is possible to live without Github.  If you aren’t using it, then I would seriously look at switching over.  The only drawback to it is their strange payment levels, because of the limit on private repositories you’ll often have to pay for a much larger package than you would need (it basically amounts to a dollar per private repository).  Other than the payment schema (which still isn’t very costly) it is probably the best investment in easily adding and managing your projects.

Chat System

Most of PBG’s projects are usually done with Lynn and I, so we just use Gtalk for our messaging system.  As soon as you add a third person however, you need a place to go to type questions and ideas where everyone can read them.  Preferably a place that is logged and allows you to upload attachments.  For this I would recommend Campfire the multi-line paste tool isn’t as nice as Pastie or Gist but it does allow you to fairly simply paste a chunk of code and have it easily readable by everyone.  It allows you to upload attachments or paste picture urls and have them show up in the chat.  It’s a great tool for talking to everyone (even if they aren’t on the same work schedule as you, since the chat log will always display the entire conversations).  It’s not all that pricey either, which means it’s great to try and see how everyone gets along using it.

Thought Process

With multiple projects it’s very easy to get overwhelmed.  If you have 5 different projects open in TextMate, 5 different terminal tabs running servers on 5 different ports and you jump between the projects fixing bugs and working with different people on the different projects then you’re likely to lose your mind.  Development requires your mind to warm up to your project.  The flow of one project is often vastly different than another project (an online classified site has a different mindset than a life streaming site), so set a side time where you focus on one project (a couple of hours, a day, a week, whatever) so you can get into the mindset of the one project.

Line your ducks up before shooting.  I’ve found that using the ticketing system to dictate where I need to go and what needs to be done works the best.  I make myself tickets for everything, from features that need to be completed, to a link that needs to be added on to the page.  Then once I’m in the flow of that one project I can burn through all the tickets quickly and efficiently.  The best part about using a ticket system is that you can think about the project any time you want, come up with a good feature idea and submit your self a ticket explaining it, then forget about it.  Trying to juggle ideas around your head will only lead to you missing something that you thought was wonderful and having a coworker ask you why the feature you thought was such a great idea was left out.

Write notes to your self in a centralized place.  Commenting your code and documenting what you’ve done is probably the one most noticeable failing in every developer I’ve met, and this is usually because the developer has all the commentary for the code written up in his head.  I know when someone asks anything about any of the projects I’m working on, I can usually tell them what file they need to edit, where they are looking, what the variables are named, what method is doing what, etc.  The problem with this is that the more projects that you are involved with the more likely it is that you’re going to get some things confused.  When I was doing 2-3 projects at once this wasn’t a problem, but when you start to get into the double digits this problem starts to show up.  My solution to this is to write little notes to myself and others explaining what is going on, similar to actually documenting my program.  This helps because now I don’t have to keep everything that is going on in memory and people don’t have to ask me questions that would be trivial to answer themselves if it was written down.  It is more work, and it’s dull work that seems to have no purpose, until you go back into a project after a month break and can just quickly read over your notes and get back into the swing of what you were doing and how you were thinking.

Try not to leave things hanging.  Unless you are working on something daily, you’ll want to try to avoid leaving things half completed.  Finish out tickets completely and get to a good stopping point before you close everything out.  That way you don’t need to remember exactly where you were at the next time you start up.  If it’s unavoidable and you absolutely have to stop half way in then write your self a detailed note on where you were at and your current thoughts on how to proceed.  This will make sure that you can pick up where you left off and hopefully put the finish on it before you have to stop again.

I hope these thoughts help.  With Rails development being cyclical in nature and companies managing multiple projects at the same time this issue is going to be cropping up more and more.