Language use at REA

As previously discussed we’re pretty keen on micro services at REA. Our delivery teams are organised around small, autonomous “squads” that get to choose pretty much any language and technology stack they wish to implement their solutions.

This inevitably leads to a fairly broad church of language use. 🙂

Language use across all repositories

That’s a graph of the 14 most commonly used languages across all of our Git repositories. Ruby is over-represented because it is widely used for tooling and deployment scripting, leading to lots of small repositories. But it’s also used in lots of apps.

These numbers should be taken with a grain or two of salt. First of all, only repositories that belong to “organisations” were counted (i.e. personal forks, side projects, etc. were excluded). Secondly, GitHub tries to guess a repository’s primary language. This guess is not always perfect. But it serves as a decent first approximation.

That’s across all of REA, but what about within organisations?

Percentage language use by GitHub organisation

There’s a bit of “lies, damn lies and statistics” about this graph too, because the “organisations” we use in GitHub don’t always map very closely to applications or systems. In fact, they’re more likely to map closely to teams and squads, which may be responsible for many apps. But you can clearly see the predominance of Ruby (with a couple of notable exceptions…) and shell. And after that, a long tail of language diversity.


  • Duncan Bayne

    Mike, what other stats are gathered for the projects on a per-language basis? It’d be interesting to see code change, defect rates, longevity (esp. of library code), etc. etc. The obvious ‘lies, damned lies, and statistics’ caution would apply here, in spades, but I think there could be some interesting observations to be made.

    • Hi Duncan. We don’t keep any defect rate of other out-of-band stats that I’m aware of, but you can glean some interesting insights after the fact with tools like Measuring things like defects can be fraught on “agile” projects due to the way work is tracked, but it’s certainly something that we can get better at.