Not performance but scaling people.

What are the conventions and ideas to consider for your Scala projects when your project/department/company receives a lot of funding to scale the head count massively? What are the best practices, competing ideas, potential pitfalls, shared battle wounds, experiences?

With references from a games studio that quadrupled to 200 employees in a year, and a public sector department that grew from a few teams to 30+ teams and over 200 Scala developers.

How does a wide range of experience and skill level affect conventions for coding style, functional approach and frameworks used. And related issues with outsourced scaling.

Essential practicalities such keeping libraries, frameworks, Scala versions up to date across 10s and 100s of projects, using sbt-bobby and alternatives. How to prevent bottlenecks between dependant teams and projects, and continuous local integration with other teams' microservices snapshots. Using tools such as github.com/HMRC/service-manager. Touch on how automated scripted versioned tooling for everything with easy management reduces friction.

A lot of conventions (some quite firm) but no rules. In the end scaling Scala can be done and done well.

Ivar Abrahamsen is a London based consultant at Eray by Flurdy Ltd (eray.uk). He is an experienced developer and architect from a mix of large consultancies, telecom, finance, public sector and flashy startups. Opinionated, mostly wrong and hopefully still learning. He rants at @flurdy and writes whilst learning at flurdy.com.