Ship Small, Ship Fast: Say No to the Mega PR

There is a recurring trend in software engineering:

• A developer is assigned a big project with a timeline extending over multiple weeks or months.
• The developer starts producing code, pushing each new changeset to the organization’s code management platform (e.g., GitLab).
• The changeset (Pull/Merge Request) grows bigger and bigger.
• When it’s time to ship the project, the developer asks their team to review and hopefully approve the changes.
• It takes time for someone to fully understand and review the code and provide approval.
• Finally, significant product or technical problems are detected in the MR, delaying delivery.

I have fallen into this trap many times during my career. I’ve had to organize mob reviews to explain the many intricate changes in my Merge Request and how they relate to one another. Yet, I was never fully confident that the review received the level of attention it deserved, given the complexity of the changes.

Today, I want to advocate for an alternative approach: ship changes as fast as possible, with changes as minimal as possible.

The Benefits of Shipping Fast and Small

• Quicker reviews 🖍: Smaller MRs are less intimidating for colleagues. They can easily fit a review session into a short gap between meetings or tasks.
• No more last-minute merge conflicts ⚡: Once a small changeset is merged, others must adapt to your changes, not the other way around.
• More thorough reviews ✏️: With smaller MRs, reviewers are more likely to carefully read and understand your code rather than skimming through huge amounts of files to meet time constraints.
• Reduced risk of late-stage architectural criticism 📉: It’s harder for someone to come in at the end of the project and say, “Whoa, we should have designed this part differently.” If the design has been in place since the first merged MR, you can easily defend your approach.
• Faster detection of QA/CI/production issues ⚠: Even unfinished changes, if pushed to production early and tested (even for non-customer-facing aspects), can help identify problems like performance bottlenecks, infrastructure needs, QA tooling gaps, observability issues, and more.

A Call to Action

I hope this article encourages you to ship your changes as fast as possible, especially when working on long-term projects. In a future article, I’ll share practical tips on how to achieve this approach effectively. Stay tuned!