Communication Breakdown

(Crosspost from medium.com/@kpgalligan)

There’s a really great blog post about code sharing from the Slack engineering team. If you’re into this kind of thing, you should totally check it out. I really like the focus on the why’s of decisions. About language, what is/isn’t shared, etc.

There’s really a lot of good info to unpack here, but I want to comment on one part specifically. I’ll confess, I had originally skimmed the post and wrote my post as a “yeah, but”. Before hitting “Publish” I went back and read it fully, and am now changing this to a “right on!” with a bit of “yeah, and” thrown in. The Slack team encountered and addressed the issue I was going to discuss. This issue extends beyond just “shared code” and comes up in many areas of large product development.

It’s the built-in, one-way conversation of delivering a packaged bunch of code that the downstream team can’t edit.

In my experience, having specialized teams and parts of code is good, but having siloed teams and code is bad. Or at least it’ll make some things more difficult. Specialized means, in this case, the shared code developers do the majority of shared coding, and they “own” the shared code, but other developers can debug, edit, and commit code back. Siloed means they can’t. It means code is developed, verified, tested and delivered and can only be run.

LibSlack started as siloed, but became specialized.

The difference is subtle, but critical. It means your upstream team needs to be a lot more correct, or you’ll impact downstream. And just to be clear, since your upstream team is not omniscient, they won’t be always “correct”. Mobile developers should have a visceral sense of this already. It’s the server api team vs the client dev team. Not being able to run the server locally and step into/edit the server code creates a significant bottleneck for development. The api team will often not give you every piece of data you need, or create a multi-step operation that will present transactional issues in a mobile context with questionable connections.

That same type of situation will present itself if you’re siloing your shared code, for the same reasons.

Sometimes you need that separation. As systems are serving large existing customer bases, you have many devs, etc. However, if you have that separation, the upstream team needs to be a lot more correct all the time, and when they’re not, the downstream team generally needs to wait weeks.

Code is a form of communication.

Even if the downstream team can only push PR’s, and they’re always rejected as a matter of doing business, editing code and submitting PR’s is a method of communication. Rather than a meeting or a google doc (or a Slack message 😜) explaining what you’re thinking, a code diff can often say what you’re thinking in a much more clear fashion.

That, of course, impacts more than just your repo design and development process.

Choice of shared language will be impacted by the desire to let other devs edit the shared code, as well as training and recruiting.

We’ve generally avoided C++ as a shared code recommendation because C++ is a pretty scary language for lots of people (myself included). On some level C++ feels like, “Hey kid! Here’s your memory. Don’t hurt yourself…”. The other shared code extreme is Javascript. While I wouldn’t exactly call the structure of Javascript “safe” in a lot of ways, you can’t mess up threads, and pointers aren’t a thing.

If there’s an overarching message about what the shared code landscape will look like in the near future, it’s that there isn’t a best choice for everybody, and a lot of options in between the extremes are coming along.

Not that Slack shouldn’t use C++! Sounds like they’re doing an amazing job solving the problem.

Wonder how Rust would’ve worked out, though…

Well, the interop works but could use something like Djinni. Have to look into that Djinni situation. Interop is hard. That’s another overarching message. Lots of messages.