Errata

I'm reading this on Safari, which is why page number and location on page are NA.

In Chapter 4, section "Common Biases and Nudges", subsection "Law of the instrument", there is something said that I believe is consistent with other advice I've seen, and tends to be a mistake when taken literally, as many organizations do.

In the list of examples of things that demonstrate this problem, there is "telling people what to do in a highly distributed team building microservices". This is worded somewhat ambiguously, but I believe the basic idea reflected here is that teams building microservices are typically independent, and using self-organizing agile teams, so "telling them what to do" is not constructive.

I have lived through a "cloud native" transformation in a very large company, so I think my experience is relevant. It is only a single data point, technically, but a very large one.

In large organizations using agile to build microservices, teams are composed of somewhat inexperienced developers. Management reads advice similar to what I cite in the book, and they assume that these inexperienced developers in self-organizing agile teams will automatically understand how to write quality code, how to properly review other people's code, and many other things that we improperly assume proficiency in.

In these same organizations, services typically interact with messages defined by an API set by at least one of the service's teams. These apis are defined by those same inexperienced developers. Since no one is telling them what to do, they construct ad hoc message schemas with varying adherence to common-sense rules. Two services that pass the same kind of information will use differing property names, for the same information. This happens because there is no schema governance in the organization, because no one is telling them what to do.

Even in an enterprise application with clean separation between interfaces, you still have to have common standards and various levels of governance.