Ideal team size for your next Facebook project

Ivan Moscoso, Monday, February 11, 2008 @ 12:36 am

I recently worked on a Facebook application for one of our clients.  This turned out to be our first collective experience building for Facebook, and it involved a mixture of re-using existing web services and building new ones for use by the same infrastructure.  All in all, a challenging thing to build and deliver given a relatively short deadline.

While there were many architectural considerations at hand, one of the interesting aspects of the project for me dealt with how we structured our team and went about tackling the problem.  As a result, I have a bit of advice on team size for those of you considering similar projects with an existing team at your company.  But first, a little history...

The only thing that was clear to all of us before the project kicked off was this: that the scope of the project was anything but clear.
While we had worked on some preliminary analysis and modeling of the
problem domain (i.e. the 'what'), building services for use by Facebook
as well as the existing infrastructure required addressing a few
technical issues (i.e. the 'how').  By the time we were given the green
light to start work on the Facebook component, we scoped out enough
work for a team of only four developers-- a much smaller team than some
had guessed at earlier.

I think everyone in the team (both Pathfinder employees such as
myself, as well as the in-house developers) would agree that the small
team size ultimately worked to our advantage.  Much of our initial work
involved investigation, weighing our options based on what we
discovered, and evolving the architecture accordingly -- activities
which require too much internal coordination in larger or more
distributed teams.

So how did it work?  We had morning standup meetings (the occasional
afternoon standup on particularly busy days when issues came up).  We
were sure to talk through any changes in design or direction.  We
documented things on the wiki that made sense to document, etc...

You might be wondering by this point what team size has to do with
Facebook per se (after all, 'Facebook' appears in the title of this
post).  And there lies the lesson in it: developing a Facebook
application for an existing infrastructure is less about understanding
Facebook than it is about managing technical risk-- particularly when
it comes to the question of scalability.

"How scalable does it need to be?" is not just a question
posed on the last slide of a PowerPoint presentation while you are
waiting for the lights to turn back on in a room full of your peers.
When the size of your user base is unclear (as it often is with sites
like Facebook), scalability is the essential question.
That said, the question is almost rhetorical when the work involves
integrating disparate systems.  And it is a question that I'll tackle
in future posts, but I mention it here because I believe it is the kind
of question that a small team, working on-site and iteratively is
best-suited to answer.  And it is rhetorical in nature because the
"answer" to the question is never really "the answer", but rather a
series of approximations to "an answer".  And this is not a number in
some guy's head or a series of lines on a chart somewhere-- it is a
combination of design + testing + profiling, backed up by a certain
amount of contingency planning along the way.

This contingency planning aspect involves making parts of the system
malleable enough as-you-go so as to allow quick changes in response to
issues that arise (or are likely to arise).  And this planning
can not be done up-front.  It requires a bit of creative thinking along
the way, and occurs primarily through the development process itself.
Your team starts to see how the parts of the system scale in proportion
to best-case, worst-case, and likely-case scenarios, and you make a few
educated guesses.  But more to the point of team size, you need to
communicate all of these thoughts and ideas effectively across the
team, distill them and plan those contingencies accordingly for the
life of the project.  Everyone needs to understand these issues and
feel comfortable explaining them to each other.

To an experienced team this all comes as second nature no matter the
size, but when starting out on a new project, small teams tend to get
better at it faster. Throw in an unfamiliar API and a short deadline,
and prepare for the realization that less is sometimes more.

So what's the answer?  Is it four? Is it eight?  Is it ten?  Well,
the answer depends largely on your development team, how much
integration work you require, where you need to budget, etc..  And only
after painstaking analysis and hours of meetings will you arrive at the
right answer for you*.

*(and, oh, that answer?  It's 'four').

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment