Trust > Processes

And thanks Jos for writing on the topic!

I wanted to follow up on my previous post, and then, with no coordination whatsoever, Jos Visser published a piece that walks the reader along the same lines. Also, thanks to my friend and colleague Joao for making me phrase the thought even better.

Let's put aside microservices and API contracts and schema registries, and think big.

The tech-savvy inhabitants of our planet, who enjoy the benefits of what we call a civilized society, seem to agree that, on quite a few levels, regulation, a.k.a. the social contract, is a net positive.

• We are quite happy we have aviation regulations when we board planes or wait for our loved ones at the airport.

• We got used to bureaucracy when it comes to buying or selling real estate, because it's the type of a transaction where safe is better than sorry, and another day or week or even month is generally acceptable.

• Similar things can be said about driving licenses, food & beverage control, anti-monopoly committees, etc.

At the same time, we appear to be ignoring the elephant in the room. This elephant is that when it comes to large-scale, a.k.a. enterprise, software, the processes we put in place to reduce room for error often deal more harm than good.

Would you get into a self-driving car if the software that runs it is built by a teenage prodigy in a garage next door? I doubt it. But when it comes to the end-to-end experience, as the end users, we are, statistically, happier when using products built and run by small teams, compared to those shipped by large corporations.

Moreover, if you interview for a high-impact team or project, and if the team wants you, pretty much every single person you speak with, from lowly-leveled engineers, through the team leads / managers, and all the way to recruiters / directorss / VPs / HRBPs / C-levels, would be selling you a simple message:

• This team is a high-octane startup within the large organization!

And your interviewers — when it naturally comes to you asking questions, and when you ask an obligatory question of how are the processes structured — would tell you up front that inside the team there is a lot of flexibility, while in the broader org … well, things are, ugh, manageable, but not that great.

The message of my previous post about schema registries and API contracts is not just that they should be the by-product, not the end goals. The idea of that post is to make my dear readers stop and think: is all this complexity we have to deal with in our professional lives as software engineers really necessary?

Because, often times, the answer is no.

Often times, one would actually do well, both in their career and in their job satisfaction & work/life balance, by standing up and asking: Why? Why do we maintain this process when it's evident that the costs the organization incurs by us following this process just do not justify the benefits of our product being, presumably, more stable at the end of the day? Won’t we be better off without it?

Or even: Can I please take a week of my daily duties and fix this process for everyone on the broader team?

In an extreme case, when some process is clearly making the product less stable, asking up front "why don't we ditch this process?" is the best thing a strong self-aware engineer can and should do.

In my post, I took the example of API contracts and schema versioning as an example. And by mo means I am advocating to not use semver and to not keep backwards-compatible versions available concurrently for a while. Also, I know well that making a change that affects multiple teams is an order of magnitude more difficult than making a change that is fully contained within one team. Duh.

But if something could be a change made by a single person within half an hour, had all the code been in a single repository, had the built toolchain supported static typing and/or proper linting, and had all the unit- and end-to-end tests been in order ... if the above can be true, if only in some imaginary universe, then it’s our duty to stop and think: are we, as the industry, really following the right path by turning the idea of microservices and components decoupling into a sacred cow?

Because, I, for one, believe that pragmatically taking only what benefits our processes, and boldly saying "no, thanks" to the rest, is just a better way forward.