HN Breakaway: Facebook’s code quality problem

A few days ago I stumbled upon a quality post on Hacker News about Facebook’s Code Quality, specifically outlining their iOS app.

I recommend you read the post, but for those who are too lazy — Facebook code quality is probably not what you expect due to the break-neck speed and scale they’re working at. With hundreds of engineers and thousands of classes in their iOS app alone, there’s little chance a high level of code quality is kept.

As usual, the HN comment section offered multiple views, from “You can’t criticize, you don’t work at that scale” to “I worked there, it was a crazy”.

To breakaway from the original article: When is it acceptable to throw standard conventions out and cowboy it?

In my current role as a mobile lead I get to work with junior developers that are still finding their feet. It’s been a learning experience for me and my colleagues (which I’ll discuss in a later post). I’ve broken down developer learning progression into key stages that I’ve stumbled through:

  1. Doing it the wrong way.
  2. Learning how to do it the right way
  3. Understanding how/why you did it the wrong way.
  4. Doing it the right way.
  5. Understanding when to do it the wrong way and when to do it the right way.
  6. Using automation to warn you of the when you’re straying too far back to point 1, while keeping a healthy balance of right vs. wrong based on scale and speed.

These aren’t easy steps to follow, and many developers land up at step 5 and stay in a strange cycle between 1 and 5. I can admit that I’m still trying my luck with step 5 and 6. It isn’t a walk in the park, and takes experience to better understand engineering tradeoffs.

In the end, is it okay to cowboy-code?

When one reaches a certain scale, standard conventions aren’t going to work for you anymore — you’ll need to forge your own path. In the “hacker” culture of Facebook, it seems the concept of “move fast and break things” is a major part of the iOS engineering strategy. Facebook most likely has great CI and deployment tools that ensure the app is in a working state before shipping, but as a developer one should also understand the engineering tradeoffs that working in an unstructured way has on the overall longevity and “development team motivation”, and not take cowboy-code as the norm.

I’m increasingly faced with similar engineering tradeoffs in an agency environment related to time and resources which I am yet to define boundaries, but in the coming weeks I’ll be looking to draw up a framework to ensure a more controlled, responsible codebase and development process.