Frank points to an interesting interview of Eric Costello on the development and evolution of Flickr. What caught my eye was this statement from Eric:
But we also have a very agile development process. We deploy code to the site maybe 10 times a day on a busy day. And we’re constantly adding new features, small and large, even though lately it’s been relatively small features, sadly.
I assume that most of the ten changes on a busy day are cosmetic, but still, that's very rapid, and it got me wondering about their development process. It turns out that Cal Hendersen of Flickr is giving seminars (in London) on their development process, which Tom Coates writes about here.
I'm most curious about Flickr's approach to testing. In my experience, changing a production site ten times a day can only work if you have very effective automated testing. This is even more crucial when you're dealing with a distributed app, where developers in one area can make a perfectly reasonable change which passes their unit tests and local functional tests, but has unexpected consequences in wider system integration. Without thorough, automated functional tests, it's only a matter of time before you'll get blindsided. If anyone has details on Flickr's strategy for testing, please share.
How Flickr's development process will mesh with Yahoo's, now that they've been acquired, will also be interesting to watch. From reading the above articles, my guess is that they'll probably blend well. My understanding is that Yahoo does not formally QA much of the software deployed on their site, but rather relies on the developers of each property (as the various components are known) to test the software themselves and deal with operational issues that arise. That's an interesting approach, but it can lead to wide variance in quality between properties. But since this already seems to be Flickr's modus operandi, and since the Flickr team seems to really care about quality of user experience, I'm sure it will work out well.
Comments