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 affect Java, Scala, Clojure and Groovy — languages heavily used in systems relied on by the vast majority of people around the world.

It may not be surprising after the long debate on how lambdas would look in Java, but the authors sprinkled remarks like the one below throughout 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 bothered me, as I believe it reflects the horrible state of our industry when it comes to having a serious debate about an important topic without bias or emotion. I guess the fact that we borrow so many terms from other sciences and disciplines, yet came up with bike shedding ourselves, says 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 many benefits to proprietary software development, but it seems like these kinds of irrelevant debates also made their way from those late-night someone is wrong on the Internet arguments into 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 you that this strategy has failed me for the vast majority of attempts. People just won’t stop talking about whatever detail they want changed, 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 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, it 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 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 migrating to whatever the vocal majority (or minority) wants is going to be a bigger investment. We recently had a case where there was a debate over the use of Finagle’s Futures versus Scala’s own native implementation. If you are familiar with the history of Futures and Promises in Scala and the JVM, you know that implementations of the concept in the earlier versions of 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…

It turns out that EPFL, Typesafe, and Twitter got together to produce what has been 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 so that with just a handful of implicit conversions we can make them work together.

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. Adding the implicit conversion meant that much of our code would end up looking something like this:

  1. Get a TwitterFuture from the inbound request
  2. Convert to a ScalaFuture for our application logic
  3. Convert it back to TwitterFuture to send to 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 it 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 of these no-op conversions make me nervous — especially around thread pools. This was a case where the different sides sat down and agreed on 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 was happy enough with. And I think that, as a leader within 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 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.