Fuckup: Programming Languages and Organizations

Some years ago I witnessed a fuckup which let to the creation of our Rules of Play and the need for a macro architecture and guidelines.

In the early 2010 Scala as a functional programming language became very popular. We were a Java Shop with an occasional Groovy service. All JVM based. One team decided that they wanted to try out something new and went for Scala. It was cool, new features, functional, less boilerplate. It was hype.

As you have it in your head right now: But hey, there must be some governance around this. Yes, we had. But not as much as we needed to. We were heavily growing, we scaled from 10 to 120 people in 2 years. We were distracted. So much was happening all at once.

Software was written, the product owner like the outcome. At least one other team tried to emulate the functional style in Java, where everything at the end had an .apply() method. The idea was spreading.

The intervention came late. The Head of Architecture stepped in and made it clear, that the course had to be reversed. Introducing in a growing organization with existing hiring, a functional language was too much at this point. This needs to be rewritten in Java over the next few weeks.

The story could end here.

What did happen was that the product owner did not wanted to put time aside for a rewrite with no new features. I can only imagine how the developers tried to convince the PO to migrate away from their beloved Scala. At the end the team happily coded away in Scala and nobody noticed. Until one day, weeks later. So much code was written already and the pressure was even higher to deliver, that nobody considered a rewrite anymore. So we had now officially Scala in our Tech Stack.

This all worked all nice under the circumstances until the first Scala people left and others had to take over. They did not know Scala. They had to learn it. And some did not want to.

We kept Scala alive. Over the years, we always had to make sure that we have 2-3 people knowing Scala are in that team. As the hype dried down, it was harder and harder to get the right developers.

People leave, but technology stays.

We fucked up.

After all of that, we came up with two rules regarding programming languages.

• It had to be JVM based
• If you want to introduce a new language, you need to convince the management team, that the benefits outweigh the costs.

This way we could still introduce a new language and get the benefits but only after all relevant arguments were heard.

Years later, we introduced Kotlin. In another company, one person was advocating for Rust. We were a Javascript and Go shop. We did not introduce Rust.

What did I learn

• A few hard guidelines are important. There should be only a few and these should be strict. Some
• Product and Tech need to be aligned. Because of this misalignment, the product owner did not have a chance to understand the tech implications for the company and the product of using a new programming language.

P.S.: It just happened to be Scala, it could have been any other language.