Just last month, industry legends John Rose, Brian Goetz, and Guy Steele published a paper draft describing a very important change proposal to the JVM, with the potential to impact Java, Scala, Clojure and Groovy, languages heavily present in systems used by the vast majority of people in the world.

It may not be surprising after the long debate on how lambdas would look like in Java, but the authors sprinkled remarks like the one below all over the text, certainly to try to get comments to focus on the actual proposal and avoid bike shedding:

Using a strawman syntax (please, no comments on syntax!), we could express our Point example as a value as follows:

This made me upset, as I believe it reflects the horrible state of our industry when it comes to being able to have a serious, non-biased or emotional debate over an important topic. I guess the fact that we borrow so many terms from other sciences and disciplines but invented bike shedding ourselves tells a lot?

In my experience, open-source projects tend to be a haven for bike shedding. The adoption of their practices by the industry brought to proprietary software development many benefits, but it seems like these kind of irrelevant debates also made their way from the late-night someone is wrong in the Internet debates to our 9-to-5 lives.

Whenever some heated debate starts, I try to first ask myself: “is this really worth the time?” Usually comparing the two options with a pros/cons list can give you a good perspective. What you will often find is that all alternatives are equivalent one way or another. It is just a matter of opinion. In Brazil we have an old saying which goes like “opinion is like a nose, each person has their own” (except nose is not the exact body part we use…), and nothing bores me more than someone pushing their opinion as fact.

In the past, when debates like these happened I used to try and convince my peers of the irrelevance of those discussions, a bit like the authors in the quote above. I can tell that this strategy has failed me for the vast majority of attempts. People just won’t shut up talking about whatever detail they want to change, and even when you finally drag them to talk about something else they will still find a way to add a sarcastic, passive-aggressive, or just plain mean ps. note, reminding everyone that they haven’t forgotten.

What I have tried to do recently is to try to identify the proposed alternative that will make the majority of people shut up, so that maybe we can get back to work even if a tiny group is not too happy.

This has worked pretty well for me. A couple of years ago we had a case where a given system was written with Scalatest as its unit-testing framework, but people saw a presentation on Specs2 and started a debate on what to use. If there’s one thing that more than a decade of Test-Driven Development has taught me is that these frameworks are very much equivalent. All you need is a couple of pre/post hooks, integration with IDEs and some other tooling and they’ll all do just fine. While the debate was still going on in the team’s mailing list, my pair and I made a Pull Request converting all tests to specs2. Funny enough the Pull Request spawned no comments.

There are times, though, when the migration to whatever the vocal majority (or minority) wants is going to be a bigger investment. We had recently a case where there was a debate between the usage of Finagle’s Futures versus Scala’s own native implementation. If you are familiar with the history of Futures and Promises in Scala dn the JVM, you know that implementations of the concept in the first many versions in Scala and Java were not very useful as they weren’t easy to compose. The result was many, many libraries implementing their own Futures and Promises —to be honest, we even have our own com.soundcloud.Future used by some pre 2.10 systems…

Turns out that the EPFL, Typesafe, and Twitter got together and formed what is now available since Scala 2.10. This video by Heather Miller is very helpful in understanding the history behind it and how it now works. By design, the implementation is compatible with Twitter’s, so much that with just a handful of implicit conversions we can make them play with each other.

This sounds like the first example I gave, but considering that at SoundCloud we use Finagle a lot, the vast majority of our code relies on Twitter’s implementation. Having the implicit conversion added meant that most of our code would be something like:

  1. Get a TwitterFuture from the inbound request
  2. Convert to a ScalaFuture for out application logic
  3. Convert it back to TwitterFuture to send and receive from back-end systems, memcached, mysql and anything we use a Finagle service for (which is pretty much everything RPC)
  4. Convert it back to ScalaFuture to apply more application logic
  5. Convert to TwitterFuture to send it as a response

Now, as someone who is on-call for a lot of our services (at SoundCloud engineers are in the on-call roster for the systems they build), all these no-op conversions make me nervous —especially around thread pools. This was a case where the different fronts sat down and agreed upon a long-term plan:

  1. We will migrate to the standard Futures as soon as possible
  2. We will help Twitter and the rest of the Finagle community with their efforts to migrate from their own implementation to the standard library’s
  3. For now, we keep using Twitter’s

Even this simple plan was crafted after many, many emails, but at least we came to a solution everybody is happy enough with. And I think that, as a leader in the group, this is one of my main responsibilities. Jason Liszka wrote recently:

Good tech leads listen and encourage debate. When the team is unable to resolve a debate, they describe a process or framework of thinking that would help them resolve it. They don’t enter discussions with foregone conclusions, and always allow themselves to be persuaded by great ideas. Bad tech leads allow debates to go on for too long without resolution, hampering the productivity of the team. Others cut off debate prematurely, dismissing new discussions by saying the matter is “already settled.” Bad tech leads believe it is more important that they win the argument than that the team reaches the right decision.

And I fully agree. Don’t let those mailing list threads or Pull Request comments go on forever. Even if consensus can’t be found I am sure that there is a way for both sides to meet in the middle. Keep in mind, though, that often times the best way to achieve that is by letting go of your own personal preferences, and that is what’s expected of a good leader, at least by me.