lixo.org

I’ve always been trying to understand a little bit more about project life-cycles: how and when do you consider a codebase mature? When does it become considered “legacy” code that people would rather rewrite than fix?

So equipped with git-iterate, I ran flog over the Ruby on Rails code, dating back from its first commit: in four years, it went from the loudly announced opinionated web framework that was promising to take over the world to something that actually accomplished it: tons of start-ups are using it all over the world, and there’s a thriving market for jobs and books and brought Ruby adoption into the near-mainstream while at it.

Meanwhile, the complexity of its code steadily increased: from roughly 16k flog points to ~95k, which is quite a big jump. I was tempted to cry “bloatware!” when, investigating further, I noticed a plateau around 4/5ths of the chart: the tests were increasing, but the code was actually stable or becoming simpler; new features added and bugs fixed without bloating it up!

That’s what I wanted to see in a mature and stable codebase: people begin finding analogies and abstractions that fit the solution a bit better, and small improvements pile up until you see most code size or complexity metrics decrease. It’s still no guarantee that the right problems are being solved, but at least it states that the problem it is solving is being solved well.

You might be asking yourself what happens towards the end of the chart, where there’s a big spike. Near the end of March, Geoff Buesing added an abbreviated version of the TZInfo gem, which is one of the steps taken toward getting timezone support going, one of the biggest new features in Rails 2.1. While it could be considered bloat, not including a dependency on another gem keeps things a lot easier for a bunch of people (plus, if you happen to have the tzinfo gem with a more recent version, it’ll just use that).

In conclusion, good work Railers!