Thursday 2016-10-13

A snippet from Matt Ranney's talk on scaling at Uber caught my eye:

Microservices are a way of replacing human communication with API coordination. Rather than people talking and dealing with team politics it's easier for teams to simply write new code.

Once upon a time, I was part of a team that built the datacenter equivalent of microservices. While we did some "cross-training" for essential services, everyone worked on their own stuff.

One day, one of the guys on the team comes to me and says he's leaving. I ask why, and he says that he wants to go work on a more meshed/inter-dependent team.

It seemed like he was punishing the team for having a better architecture.

Say you had a monolithic steaming-pile-of-code, people working on that codebase would be forced to coordinate just to get anything done. The bad codebase can have a positive team dynamic of working together to get through the pain of making a point release.

Now assume the future looks like operations-driven development: the architecture is such that every self-contained project only takes one person 8 hours to make. There is no team coordination required ( no steaming-pile-of-X to deal with ), so people complain that there's no feel-good social element.

What do you do? Punt the problem to HR? Throw per-language outings (the two ocaml people finally meet!)? Set up lunch-based teams (philly cheesesteak team today!)?