Pull Requests are an Anti-Pattern
The Need for Continuous Communication in Software Development
Communication is fundamentally broken in software development. Say you and I were devs, on the same team. We work remotely. Your name is Sue.
(on Slack)
Jess: @Sue I’m updating the runner func, can you check the cmd calls?
Sue: sorry which one?
Jess: in goOracle.py
Sue: goOracle.py? Wait, which repo are you in? Can’t find the file 🤔
Jess: hang on, I’ll find it on github…
Sue: got it, what have you changed the commands to?
Jess: hang on, I’ll make a gist...
(on Gist)
Jess: does it make sense to use the run command or should
your runner class handle this?
Sue: hmm... where are you calling write_running?
Sue: can you create a WIP PR so I can see the rest of your code?
We’re about ten minutes in and haven’t even started talking about the guts of the problem. Our chat is spread across Slack, Gists and PRs - making it very hard for anyone else to follow along.
The dev’s mental mode is accustomed to working with complex, disparate systems. This has spilt over to our processes of collaboration. We accept that basic comms requires a lot of setup overhead, because everything about our work takes a lot of setup overhead (deps hell anyone?) - to the point that we don’t question that we need to make a Pull Request (PR) just to discuss code we’re working on.
PRs, which were originally intended as a final check to safeguard against errors, have somehow become the de facto tool engineers have to share knowledge about in-flight code. This creates frustration and rework and sends the constant message that your team members can’t be trusted. This is an active, industry wide problem - today:
Engineers report knowledge sharing to be their #1 problem in software development and it is the leading cause of technical debt (the cost of poor quality code)1.
Software may have eaten the world, but tech debt is eating software. Misaligned code is a compounding problem, getting worse with every new dev and every PR being made. Stripe estimates tech debt to cost global GDP $3 Trillion dollars2. A Pull Request is the 2nd most costly time to fix an error. The only worse time would be after it was let out to cause an actual issue.
There was a time where last-minute chaos at release dates was the norm - before Grady Booch introduced the concept of Continuous Integration (CI)3. Many benefits flow from CI, beyond catching bugs; immediate feedback on the system-wide impact of a local change and the frequent code check-ins push developers to create modular, less complex code.
We have Continuous Integration of written code and Continuous Deployment of integrated code. Yet, as an industry, we’ve missed the first step. We have no good way to “Continuously Communicate” as we code. Communicating and collaborating in the creative phase of coding - i.e. while sketching ideas, planning, writing - is a first class problem. Retrofitting PRs as the solution is actively holding us back.
Shifting dev comms left has a disproportionately high impact on productivity. While the following chart is 25 years old, nothing has changed (except the costs have gone up).
The future of coding is hyper-collaborative. Code itself is a snapshot in time of an ongoing process - its quality a reflection of how well the team communicates. We need Continuous Communication to bring the knowledge flow of a 3 person team to a 30, 300, 3,000 person team. As developers, we’ve focused on scaling up everything - except ourselves.
State of Software Development Report - Coding Sans 2020
The Developer Coefficient Report - Stripe Sept 2018
As part of his Booch Method in 1991
It sounds like the real problem, in this case, is communication. But the people writing are aware of it, otherwise, why on Earth are you going to share an extract of code in a Gist where you completely lose the context of the problem. And moreover, how're you starting a conversation by giving a question without contextualizing.
This sounds more like the kind of situation where a problem has an identified solution but the person thinks is better to create a new fancy product that was never necessary.
my PR (pull request - with self peer review)
James (3rd person): does this code look good?
James (3rd person): no you idiot
James (3rd person): correction incoming
James: lgtm! Approve & complete with squash merge
James to the team: Here is the PR. Let’s mob together what I did when no one else happened to be around (I don’t have full buy-in for 100% mobbing…but this is what I imagine)