Before you dwelve in other articles, it’s important that I confess my faith:
I am:
- a monorepo lover;
- a phabricator apologist;
- an arcanist workflow zealot.
(Also, I’m fond of Evan Priestley’s humour, but that is probably irrelevant.)
If this sounds heretic to you, feel free to leave. In any case, keep it in mind while browsing this site, especially if you’re about to hire me, accept some funding from me or ask me some general advice.
What follows is a succinct explanation of why I can get so emotional about this topic (if you happen to know me, you’ve probably noticed already).
If you’re in a hurry, just take this with you:
A phabricator/arcanist setup is about making developper behavior converge and reinforce it positively in the long run.
I’ve whitnessed the above through all of my 6 years of current professional experience.
Now, to some more details.
Degrees of Freedom
It’s not that you can’t reach the same outcomes – which I’ll discuss later – via other ways: the problem with most other tools and workflows is the degree of freedom that is available to you. This will require that someone with experience (and available time) takes some decisions, lays out some policies and practices and sets up a mechanism to enforce them.
From my own experience, even seniors will gladly skip specifying some rules, as this requires to put on your bad cop cap and require burning a little bit of political capital from time to time.
Instead, you may just chose an opiniated toolchain that lets you focus your decision making on things that matter: delivering value to whoever you write code for.
An Analogy
The analogy to religion is not entirely moot: religious practice comprises lots of things you may not (and never will) understand, but which may represent useful heuristics to deal with the world, in the sense that they may increase your output, your chances of success or even survival.
Phab+Arc+mono/fat-repo does exactly this: they do some choices for you and force you through certain paths that provide benefits slowly vesting as time passes, and which you will only understand later: I see this from a perspective that is now in its 6th year.
Generalising Behavior
It’s about generalising healthy behaviors: –“I need to think about where I can put this in our existing setup” instead of –“I’ll just create a new thing in a non-structured place”.
At the bigger end of the software scale, companies seem to embrace the single bucket of things approach (cf Google, FB, …) that is updated in a trunk development fashion.
It’s also about a single gateway to code review: everyone sees everything by default, which you can trim to your needs after you believe you need to.
Responsibility (and Cleanliness)
With Phabricator and arcanist, a changeset starts and ends on the command line, does not require clicking some buttons and filling a web-form each time you need to get something reviewed, and leaves your local branches in a clean state once the change set is landed.
No one can just merge it for you: your change, your responsibility to get it through. And whatever branch structure you chose to work locally remains quarantined to your system: nothing ever gets to master except a single commit per change set once your change was accepted.
You can’t predict the future
In other words, it’s about not introducing arbitrary separations, and if you need to, to make sure that boundaries at different levels of abstractions don’t correlate with each other: if you need two separate repos, don’t have two separate teams each take care of them in a 1-1 mapping. Ignoring this will get you extremely exposed to Conway’s law.
Plus, you don’t know which internal boundaries will make sense in the future, so introducing static and hard to change separations – like multiple repositories or teams that are never reshuffled – guarantees you some pain down the line when the context has changed.
In Short
Whatever you chose, keep this in mind:
Toolchains and end-to-end workflows are part of the strategic decisions a software-based company needs to make
It’s not so much about the immediate macroscopic effects – which are hard to distinguish at first – but about the hundreds or thousands of daily micro-decisions that a correct setup will nudge towards the better side in each of an organization’s developers. From a more abstract persepective:
Culture is deeply tied to behaviour, and behaviour itself is heavily influenced by tooling.
Thus, tools can help to drive a culture.
It is my strong belief that such workflows are not more widespread because not engouh thought is put into them at the beginning of a project/startup/whatever, and that once they would become really useful, habits and routine have crystalized into something that no one wants to spend energy on to change.
I’ll dwelve deeper through the above points in later posts.
In the meantime, if you think I’m a nut for liking this toolchain, let my know why on Twitter.