Big, young codebases

See also, Bazel’s time has come

In ‘Software engineering and AI questions’ I wrote:

I am partial to the ‘programming over time’ definition of software engineering which I conceptualize as two axes: time and codebase size. Most of the flame-warring between programmers online is a failure to recognize these quadrants and their various constraints.

The weekend hobbyist, the OSS maintainer, and the corporate cog all exist in unique environments that dictate what is useful and practical when it comes to source control and code review practices, build systems, testing, deployment, and monitoring.

Codebase size typically varies with complexity (it is hard to have a large simple codebase or a small complicated one) so the ‘size’ axis is also generally a ‘complexity’ axis.

Let’s visualize that:

A graph of notable codebases and their size and age

Historically, writing a lot of code took both a large number of people and a lot of time which is why there’s nobody in the sub-three year, ten million line space. That’s not true anymore; a solo dev can AI-generate their way to ten million lines of code in a few months.

The previously strict correlation between codebase size and team size is now gone, at least in the near-term. It remains to be seen whether a project which creates ten million lines of code in its first year can survive to its tenth (or even third) birthday.

For any new project, a modern laptop can store the entire codebase and its history and efficiently perform all builds and tests. But as the codebase scales to ten million lines and beyond, a series of progressive scale challenges emerge:

  1. CI is too slow to run locally
  2. Change volume necessitates a merge queue
  3. Builds are too slow to run locally
  4. The codebase history no longer fits on local disk
  5. A full codebase snapshot no longer fits on local disk

These challenges are important because they slow the rate of submitted changes which necessarily increases with codebase size. Typically they are solved with specialized tooling which a team adopts over the typical ~10 year journey from steps one to five.

If step five will instead be achieved in 24 months, does it make sense to adopt the specialized tooling from the beginning? Normally, the significant switching costs of replacing e.g. a build system can be amortized over the lifetime of the project. But if scale may be reached quickly, a higher upfront cost (for more powerful tools) could be attractive.