Flickr talk @ the BBC

In August, Cal Henderson of Flickr gave a talk to a group at BBC New Media. Here's my notes from his talk on Flickr's development team and process:

The main theme was to keep the project team small. I believe the members of the Flickr team are composed of a single creative, a product manager, a public-facing developer, a server-side developer, and a DBA. The present team size is 8 (9?) people.

The benefits of a small team were indicated as easier communication - more ownership / responsiblity of the product / and little or no paper trail. The team as a whole could do rapid releases at a stated frequency of upto 10 times a DAY (though it was unclear if these were minor changes to markup, instead of larger changes that would require more testing).

Their development process breaks down into the following structure:
1 day for planning - involving the whole team, using post-it notes and cue cards.
1 month for development
1 month for refinement

The features identified in the planning stage are priortised by a set of drivers: coolness factor, pet factor (exec wants it), user demand, and others.

The 1 month development timeframe is meant to deliver a feature as quick as possible; and permit rapid releases. The basic premise is to treat everything as a prototype; and drop a feature if it isn't working out. It is not uncommon during the development timeframe that the original spec for the feature changes due to new experience. Being able to have the flexiblity to drop or change a feature is important.

R&D is primarily accomplished by encouraging the team to experiment and do prototyping, and mashups (identifying synergies with their product and other products and building actual products with it).

During the 1 month refinement time; the primary focus is on observation (of users), tweaking, and considering the removal (deletion) of a feature.

The observation of users is mostly driven by the community forums.

Deletion of a feature is important - as it's better to cut your losses on a feature that isn't right or isn't going to work; instead of sinking more money into a losing proposition.

During releases, there is no true "testing" process - they rely primarily on the developer to ensure their code is tested. However, if a bug is found, instead of doing a rollback, they try to fix the bug on the fly and immediately get out another release. Cal mentioned they do more serious testing if they are modifying something that could have bigger impact (such as DB schema changes).

To facilitate this rapid development methodology, strong points were made on having:

1. good release tools -- one button to release and deploy apps
2. good rollback tools -- see reason above
3. good issue tracking -- metioned use of fogbugz for tracking customer-facing & internal issues. Cal mentioned that Yahoo! use bugzilla and he hates it

Flickr's architecture is layered, from top to bottom:

Presentation (CSS)
Markup (smarty)
Page Logic (PHP)
Business Logic (PHP)
Database (MySql)


Some other interesting tidbits:

- Will flickr do audio or video? probably not - as looking at a photo requires less user time (i.e. they need to invest time to consume audio & video)
- They maintain a maintainable app by ensuring strong coding standards. These standards mandate both structure and readability of code; so that it can be easily picked up by another developer
- Little or no "formal" product documentation. The code is documented (and though it wasn't stated as frankly, I took this to be "living documentation")
- Cross training is minor. A developer at one layer (say the Page logic) would be familiar with the layer above and below themselves (because they have to either build the API for the layer above, or employ the API from the layer below). Cal mentions this is partially countered by having strong coding standards.
- Low turnover of people - mainly because of an ownership of the product - motivated and interesting work. Avoid boring work, staying on the same project for 2 years, and work that stagnates - ie. has matured to a point where more time is spent on maintenance and support instead of innovation.