Interesting Data Points From How Facebook Ships Code

{

I ran across this blog entry which is an unofficial attempt by somoene to glean the internal workings of Facebook’s product and software development processes. There are some very interesting things to be noted, most of which I’ll just quote from the article directly:

“resourcing for projects is purely voluntary”

It’s interesting from this unofficial post that project dynamics are organic and based on what engineers want to work on. It begs the question of how the more difficult and less pleasing problems are solved but I would hedge that by having people who are talented and motivated, difficult and more grimy problems might be what attract people that are always seeking challenges. Indeed, from later in the article: “engineers generally want to work on infrastructure, scalability and “hard problems” — that’s where all the prestige is.”.

“Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between.  If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on.  Same for Architect help.  But in general, expectation is that engineers will handle everything they need themselves.”

This is one of the more fascinating points because it reflects one side of an approach to programming that I’ve encountered: that delivering some functionality is a process of ownership where a person generalizes across disciplines and technologies. The opposing viewpoint sees programming more in terms of division of labor with staff assigned to “tiers” of the technological back end: database developers, “business layer” or component programmers, user interface and so on. I always think of sports with this dichotomy where the former thinks of software development like basketball – a game that involves some specialization but really rewards the generalist who can play any role on a team, and football – a game of specialists where it’s a liability to do too many things since even the physique is developed on a per position basis.

Many people acknowledge generalists for small organization but it appears that Facebook, a company as large as they come, prefers them.

“engineers responsible for testing, bug fixes, and post-launch maintenance of their own work.  there are some unit-testing and integration-testing frameworks available, but only sporadically used.”

There are a few edits and comments to this point but the reason I find it interesting is that they are a corollary to the views that Joel Spolsky expressed on the StackOverflow podcast. Many developers, myself included, berate ourselves on a lack of unit testing with the assumption that “everyone is doing it, why can’t I?” As time passes, however, I realize that TDD and Unit Testing are very important but not essential. It’s a very unpopular opinion and while I admit that I strive to make my code testable and, especially on personal projects where I have enough control, architect my software so that it’s testable from the get-go.

}