Cal Henderson on "How We Built Flickr"…

So Day Three of my weirdest ever holiday finds me at a one-day workshop called Building Enterprise Web Apps on a Budget – How We Built Flickr. Right up front I should probably say that it’s presented by my mate Cal and I’m here courtesy of Ryan Carson and Carson Workshops, so I’m probably biased or bought or both. Nonetheless, I need you to believe that I’m enjoying it enormously. It’s very much from a software engineering / architecture kind of perspective rather than the more conceptual / design / user-facing perspective that comes more naturally to me, so it’s difficult for me to assess how accurate it is, but it certainly appears an intensely practical and rapid way of building and developing web apps (and I trust Cal enormously). The practice that he describes – interestingly – is also completely alien to the practice that I’ve observed in large organisations, which either means that one or other party are ‘doing it wrong’ to a greater or lesser extent or that certain types of organisations by necessity have to operate in different ways. I’m going to be banal and insipid and say that it’s probably a bit of both.

The day’s about two-thirds of the way through, so I don’t have a complete sense of the day, but so far I can very much recommend it. My immediate gut-reaction is that I just miss working with Cal. But since not everyone in the world is going to get that opportunity, I guess it’s not an enormously useful insight to share with the world. So instead I’m going to pick out a few of the comments / phrases that he’s said that have struck a chord with me directly.

One of the most interesting parts of the whole enterprise for me was his articulation of some clear levels of abstraction between database work, business logic, page logic, page mark-up and the presentation layer. It’s not an enormously novel set of distinctions I guess, but the level of clarity about each area really appeals to me. It’s an architecture that really supports the rapidly iterative way of operating that I enjoy and think is core to developing great online applications.

One particularly interesting chunk was about the relationships between various people operating at different layers – with the developers able to easily create page logic-level functionality that allow the designers to take it away and build user-facing features around them. This relationship is phrased as a negotiation, with the designers coming back and asking for page logic level functionality as they see a need for it (and then being completely responsible for the building of the front-end elements of the site, and for checking it before launch). The whole enterprise is around continual development and improvement and reaction, which probably explains another fairly jaw-dropping moment of the morning – when Cal revealed that on ‘good days’, Flickr releases a new version every half an hour. In order to support this kind of working, they’ve built structures that ‘supports rapid iteration but enforce at least a little rigour’. Stunning. Although clearly not right for everyone…

A lot of this stuff really fits with my aesthetics of developing products effectively for the web, because – I guess – it’s actually a very responsive and very web-native way of building. This process cycle of rapidly building, creating structures that support future iteration, being connected to the users on your site and being able to react and redevelop your proposition almost on the fly – these all seem to me to be the way that most of my peers worked before moving to large organisations that attempted to enforce standard software development methodologies on a completely different medium. And of course, it all hooks in with elegant ways of writing and producing web pages in ways that allow rapid change and evolution, making design about interactions and services and components and design swatches and aesthetics and change rather than about .psd files, yearly redesigns and top-down management (and sign-off) from a distance. I’ve had a post around this area bubbling away for a while now. I’ll probably have to write the damn thing now…

I might write more later when we hit the section about APIs, which is the area that I’ve been waiting for pretty much all day. But in the meantime, I’m going to end with a few quotes from the piece that I’ve noted down through the day that seemed kind of core to me.

‘We should listen to Donald Knuth when he said, “We should forget about small efficiencies, about 97% of the time. Premature optimisation is the root of all evil.” This is the most important thing that you’ll ever hear as a software developer.’

‘In a rapid environment, we’re going to want to make a lot of releases.’

‘It’s more important for people on a team to agree to a single coding style than it is to find the perfect style’

PS. I believe that these workshops are coming to London later in the year and I can definitely recommend that people look out for them.

9 replies on “Cal Henderson on "How We Built Flickr"…”

It’s all about lack of hierarchy and implicit trust. The two go hand in hand. And it will be very interesting to see how long a leash the Yahoo management give the Flickr team — and how much they learn from doing so.
Caterina talked to me about the relationship between GNE and Flickr, and the role of game-playing on the user side. I think there’s an element of game-playing on the development side, too.

>The practice that he describes – interestingly – is also completely alien to the practice that I’ve observed in large organisations
this is the pattern with most Effective software development (teams).
big organisations typically focus on Process, and are very ineffective for any given level of effort. they also typically have the cashflow to support a large proportion of parasitism.
effective people rely on process to, and only to, the extent it Helps the Result. process is derived from what needs to be done to achieve the goal, not the other way round.

It is so refreshing to hear of environments in which rapid development and creative thinking and problem solving like this are supported.
And the success of Flickr is a testament to what can be achieved in such an environment. Managers everywhere should stand up and take notice.

I hate to break up the chorus of cheering, but the succerss of Flickr is a testament to the massive PR and marketing campaign by it’s industry insider founders. The success of the application development is not only in getting a working product out the door in record time, it is in good usability as well. And flickr does not have a successful usable interface nor clear interaction logic. To illustrate, I’ll just refer you to thousands of flickr forum postings where users ask over and over “how do I…?” People are having a hard time figuring the damn thing out. But of course now it’s Yahoo’s problem. Good luck developers, lots of fun on the lecturing circuit!

If flickr doesn’t have a successful usable interface or clear interaction logic, what explains its tremendous popularity? Oh, right, that monstrous marketing campaign. All of those TV and radio ads, magazine inserts, and product placements in movies probably account for the success of flickr.
I’d like to hear about your successful web app. Could you give us a URL please?

Comments are closed.