[idlephysicist]

> The team DOES NOT use pull requests. Contributors are expected to be socially capable and fully engaged in the inter-personal, realtime communication that supports high-performance, low-handoff work.

I am interested to know more about your workflow given that you do not use pull requests, could you please elaborate on that?

I cannot imagine that you’re all just pushing to master.

[hmeh]

sbellware's reply says just about everything of import, but from a tactical perspective, yes, we do push to master. Sometimes we push regular commits and sometimes (if we branched) we push merge commits. We have hundreds of repos and it's very rare for there to be conflicts of note. We do reviewing as we work via pairing (and on demand, live, when necessary).

[sbellware]

I've always found it odd (at least since 2001-ish) that developers see the 1-work-for-1-person as some kind of desirable norm, rather than some arbitrary fixation that has been burned into them since the start of their careers.

It's wishful thinking at best to expect effectiveness and productivity come from the isolation of developers to their own isolated work items. It's hopes and dreams of promoted-beyond-their-competency managers to parallelize the workforce to maximum capacity, rather than to focus on the ability to make progress without slowing down, and then optimize from that baseline.

It's odd to me when someone has to call out "pairing", rather than just assume that work items are taken on by work cells and work groups, and that the more important objective is continuity of knowledge and understanding amongst the workers so that momentum can always be transferred immediately without having to reset and relearn.

The 1-work-for-1-person ethos is so obviously counterproductive that I struggle to understand how it's still so prevalent. Except that human history is rife with popular mythology, and humanity's efforts have been undermined by it for as long as there have been humans.

It speaks to the dark ages period of software that we live in that even the production systems in software work are so antiquated that they still try to grasp at the most implausible straws, not to mention ones that have already been debunked and disproven by industry at large.

It speaks to the reality that software development largely still operates as a craft rather than an industry. Software developers barely pay attention to industry as a body of knowledge, and the sorry state of both software products and software jobs reflects it.

When the day comes when "pairing" never even has to be stated, software work will have entered its modern age of industry. It should be presumed that the processes of momentum transfer between knowledge workers is the singular element that dictates whether a team can continue to build momentum in perpetuity, or sputters out prematurely early in a project's lifetime.

We always have to mention "pairing" when talking to people from that dark ages, and those people will never have a good frame of reference for it due to seeing it through the lens of a more primitive grasp of industry and the body of knowledge that surrounds it. It's almost impossible to explain a high-functioning production system to anyone who has made no time in their professional lives to become as qualified in industrial theory, organizational theory, and production systems as they have to learn the latest convoluted front-end toolkit.

We're like cavemen working with tools gifted to us by some advanced civilization. We've been trained to use high-tech, but we barely understand the systems of work that produce it, and we don't allow ourselves to benefit from the things we can learn from more advanced and more mature fields.

But then, as long as the software tooling available to us is a bad is the things that we make with it, we'll never have the buffer of spare time needed to make the study. And down and down we go.

[sbellware]

Pull requests are a relatively recent addition to software development. What did you do before pull requests? If you haven't been around for that long, and have had a career that always had pull requests, then pull requests seem like an inevitable and irreducible inherent feature of software work. But they're not inherent to software work.

I'm going to generalize "pull request" into other terminology so that I can describe the deeper issue:

A pull request is an asynchronous handoff, and asynchronous handoffs are a known sub-optimizer of production processes of all kinds, not just software. It causes batching and queueing, and the harmful effects of those on processes are also well-understood.

Why would I want to introduce asynchronous handoffs into a process that we've worked so hard to optimize at every level and in every turn?

Our process is what it was before GitHub popularized pull requests, and popularized workflows that increased the engagement with their digital product.

The problem is that developers aren't asking whether pull requests are even a good thing to build a development process around. Given the detrimental effects of instituting asynchrony as a desirable target, I find surprising that software workers have gone all-in on something that is an obvious production system anti-pattern.

But to a degree, I'm also not surprised. There's a prominence of a certain kind of psychology in software development that wants to work in isolation without having to be bothered by things like realtime communication and coordination. It's seen as a kind of privilege in that cohort of software developers, but it's one of the most harmful things that can be done to software work (or any work where more than one person is involved).

Software developers tend to be antisocial, and there are enough antisocial developers gathered in this industry that they can enable and reinforce the idea that being antisocial is desirable.

We have a zero-tolerance posture when it comes to antisocial tendencies amongst developers. Our processes are all realtime and synchronous. The level of productivity that we're after requires zero-tolerance posture with regards to batching and queueing and handoffs. We collapse the whole rotten mess of software development down to the fundamentals of production systems and reap many multiples of productivity relative to industry norms specifically by harnessing the momentum that comes from always moving forward, rather than contending with the pervasive start-stop interrupted processes that are common in software development due to failure to recognize the effects of batch handoffs.

The specific details of the work flows aren't as important to disregarding pull requests as the character and behavior of the people in the process. We're not antisocial, and we don't accept antisocial behavior in the team. We work very closely with each other in tightly coordinated and highly-communicative ways in everything we do. At any given time, a very small number of active work items are being worked by a single developer.

In the end, we know more about production systems itself as a field of study and body of knowledge than the average team of devs with 5-to-10-years of experience. And we know a lot about structural design. We marry these two concerns into a process that would be quite recognizable to someone who's studies Lean and the work methods that Edwards Deming championed that changed the face of human productivity decades ago - in every field of human endeavor EXCEPT software development.

So, for a team that is irretrievably mired in asynchrony, and operating on a belief system that has never questioned the workflow fundamentals and the detrimental effect that asynchrony has on the upper potential of productivity, I can see the utility of pull requests. But it's not something that I'd willfully volunteer for. I won't trade the luxuries of working in asynchronously isolation for the vastly-improved lifestyle of rejecting the myth that technical debt is inevitable. This is a lesson that American production industries learned when Japanese producers started beating western producers at their own game by exploiting the virtuous relationship of quality and productivity.

The lesson is that productivity and quality are indistinguishable at the the upper limits of high-performance work and work teams. The level of quality that can generate multiples of end-to-end productivity of an entire process and production system doesn't survive in the presence of a tolerance of asynchronous handoffs.

We don't use pull requests because we want to have a more higher quality of software development life, and we can't have that if we indulge our endemic sense of entitlement to working in the dark all by ourselves.

There's an old saying that was oft-repeated in the days before Scrum executed its ethnic cleansing campaign on XP: If code reviews are good, do them constantly and continuously.

We don't do pull requests because every moment of our work is a code review simultaneously with code production. When you learn how to put together an entire production system with these fundamentals as the non-negotiable parts of the work, the productivity that will emerge will be revolutionary.

Most software teams can't imagine how good and how easy software work can be when the target is the upper echelons of quality.

That said, software work has been removed from this body of knowledge for so long (largely due to the rapid increase in the software development labor pool that started around 2010) that software development culture at present at large no longer has possesses the knowledge of what mistakes are in software work.

Until software developers gain a fluency in software structural design, no amount of fiddling with team workflows will result in anything my negligible, middling improvements.