[1.Ch.] Orthcosm
I've been working on a new mantra for work. "Well-designed systems make performing correct actions easier than performing incorrect ones."
This has the unfortunate side effect of causing many technologies which are popular to be called "not well-designed" because while they may be more powerful than the tools that came before them, they also make doing things the wrong way easier than doing the right one.
[1.Ch.] Orthcosm
The biggest example of this that I'm fighting at work right now is... well, everything involving protocol buffers.
The idea of protobuf is pretty sweet. By making the interface objects between systems independent of the systems themselves, teams can update in isolation from each other and merge on their own schedule! That sounds amazing and on paper I'm sure it works a treat.
However.
[1.Ch.] Orthcosm
There's always a however.
In practice, at least at my company, this has created a perverse incentive model. If I update before my partner teams do, I can say "I'm blocked" until they take the update I pushed.
They have concerns about how I implemented my change? If they weren't lucky enough to weigh in on the PR when it went past, it's kinda too late for them to complaint. I can unilaterally turn a collaborative effort into Hobbes' Choice for the slower teams.
[1.Ch.] Orthcosm
So why does this matter?
It matters because any feature which crosses team boundaries needs collaborative engagement to succeed. Every team has to be successful for the feature to be successful.
Protobuf, as I've seen it used to date, hinders collaboration by enabling people to make unilateral changes to shared resources. This hampers velocity on every team -- the first team because they're blocked and the other teams because they have to play catch-up -- and impedes trust.
re: [1.Ch.] Orthcosm
@orrery I guess I'm not clear on how this argument differs from any other form of API whose ends are owned by different teams?
(If anything, protobufs allow the API to keep evolving and compatibility to be preserved even if either the client or the server's release schedule is lagging behind, that's kinda the point.)
re: [1.Ch.] Orthcosm
@balinares The difference is that if I change my REST interface and you break, the consequences are immediate and obvious. My lived experience with this has been that this tends to drive collaborative engagement with an eye towards zero-downtime migrations and rollbacks.
Under protobuf, one team can just "develop ahead of the other" and then when the team playing catchup tries to take the update and it breaks, it's treated institutionally as "they're not keeping pace."
re: [1.Ch.] Orthcosm
@orrery I'm confused about the "take the update and it breaks" part. (Also the part about "racing to define the object model".) Neither reconcile with my understanding of protobufs, so I think I must be missing something.
Not very important though. Have a good evening, bird. ♥
re: [1.Ch.] Orthcosm
@balinares Now, you could argue that the client has no business changing the server code like that, but there isn't anything in the technology stack that prevents it, only social contracts that only hold as long as there's pressure on them to stay in force.
In an environment that doesn't expect to have to manage these kinds of problems, their introduction can create some very bad cultural attitudes. Our org wasn't ready for them, and it's burned us.
re: [1.Ch.] Orthcosm
@balinares So, f'rex, validation rules.
Team A and B share a proto for data exchange. Team A calls Team B's servers.
Team A adds a new member to some object. Great, Team A is on v1.2, team B is on v1.1. Team B's server code drops the field it doesn't recognize. Everyone's happy.
Now Team A adds a validation rule to that member. Team B's servers will now throw an error every time Team A calls it saying a necessary field can't be unmarshaled.