We've been programming most of our lives.

We always felt software development should be simpler, more enjoyable, and more productive.

The methodologies we used at Google transformed how the developer community and we worked. It popularized Trunk Based Development and code reviews.

Automated test and build tools offered by CI/CD companies and Git hosting services have also advanced it.

*Still, there are too many workflows, practices, and tools to choose from. *

Remote work, which we have practiced since 2011, adds unaddressed challenges to software development.

Over the years, we've selected the best practices that have proven to be the most effective for us in building Android apps, SDKs, SaaS platforms, games, and more.

The result is an opinionated process of code management and development workflow we internally call "The HighFlux method".

We spend most of our time coding a work in progress, while most tools are available only once the code is ready for review.

Being lazy programmers, we wrote some code to automate the HighFlux Method, allowing us to practice it without creating additional friction.

It turned into a git client written in Rust. But that's for a different blog post.

The HighFlux Method

TL;DR: The HighFlux method is a descendant of trunk-based development and prescribes:

• Use a monorepo
• Use WIPs, not feature branches
• Use feedback early and often

Each of the above deserves its own post - but here's a short introduction:

Trunk based development

A source-control branching model, where developers collaborate on code in a single branch called 'trunk' *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after."

– The trunk based development site

Use a monorepo

Prevents dependency hell (including circular, diamond, conflicting, and, if you're really old DLL-hell)

There are so many other benefits explained in detail in this Google article. They include extensive code sharing (and duplication prevention), unified versioning, large-scale refactoring, better code security and compliance, atomic changes, cross-team collaboration, code visibility, and ownership.

WIPs, not feature branches

WIP (work in progress) is the primary work unit. It is a short-lived branch with the following characteristics:

• Small - Small changes are proven to improve code quality and the team's velocity. They are easier to review. They get reviewed faster, and they're easier to test.

  Use a series of small incremental changes instead of one big change.

• Close to the trunk - Regularly (4 times a day) rebase your work over the fresh trunk.

• Short-lived - no more than 2-3 days of work in one WIP.

• One WIP per functionality - getting unrelated logical changes into a single WIP makes it harder to roll back and harder to review & test.

• Owned by a single developer - sharing branches causes long-lived, large changes.

• Merges into trunk atomically - resulting in one commit per WIP. History becomes clean and linear, Easy to bisect and roll back.

• Visible to the team at all times - Any team member's ability to view the code being written right now has transformed our work. It promotes code ownership and familiarity by all, and helps us be more efficient: write the right code, better, faster.

Early and often feedback

• **Some changes do not need a review. **This deserves a dedicated blog post. the summary is that it can be fine in some scenarios, like a tiny change fixing typos in comments. The key is to be sure that there is no user impact risk, and that the probability of others contending against the change is minimal.

  Small pre-production teams working on an MVP, especially where each engineer has their domain, such as frontend and backend, might also find this useful.

• The start of a feature is the most critical time to review it.

• Pre-review - is done at the beginning of the work. Best done on a skeleton of code - empty methods that call each other, algorithm pseudo-code, or even off-code detailed design doc.

• It will save your teams' time, increase developer happiness, and prevent rapid tech-debt accumulation.

• Review the deliverable, not just the code - The running product: UI, CLI.

• Ad-hoc reviews - quickly ask and receive synchronous feedback for a snippet of code, a particular design, or an algorithm. The team should be able to answer such an ad-hoc review request within an hour or so.

• When reviewing others' work

  • Code reviews should be a high priority.
  • Focus on the important stuff - design, algorithm, efficiency, accuracy, correctness - NOT on code style, typos, or linting. The latter should be pre-submit hooks defined for all teammates.

• Some of the above can not be accomplished using current review tools.

How to practice?

Some practices above are easy to follow, and some require setup, automation, and more structured, opinionated tools.

Here is a list of the functionality we need. We've already built some of it.

• Every code change is part of a WIP - no "index" or "staging" area. This is a controversial topic that presents real challenges. Overall we think the benefits outnumber the drawbacks.
• *Quick switching between WIPs *- this is important for "one commit per functionality", "review the product, not just the code", and "provide early and often feedback".
• Once switching between WIPs becomes easy, it allows us to respond to review and hotfix requests quicker.
• *Easily move hunks of code and files between WIPs *
• **Sync functionality that keeps everything close to the trunk: **pulling from trunk, and rebasing all WIPs upon new changes. (bonus: conflict prevention and detection).
• Continuously push all code to the git hosting service so that everyone (including machines!) can review work in progress early and often.
• **Ability to run "machine based early feedback" for all team members. **Including pre-submit code formatting and linting, continuous security and compliance checkers while writing code, all before PR is ready
• WIP size metrics (hey! You're WIP is too big) and Review time metrics (hey! You should review this code now) to ensure WIPs don't get too big.
• Support for Pre-reviews flow and Ad-hoc reviews flow.
• Continuous history - Freely go back or forward in time.

What's Next?

This is a work in progress, and we still have much to cover.

If you're passionate about this stuff like we are and want to share your thoughts and learn more about ours - please join us on this discord server.

We hope to grow the community around the HighFlux method and bring this more productive way of working to the masses.

We (Uwe, Mathijs and Guy) are software engineers by profession and passion. We met at Google, and started our own companies since.

Throughout our careers, we felt we needed a well-defined framework for software development that improves velocity, productivity, and fun.

That's why we've been busy building the HighFlux git client in the past few months.

We use the HighFlux method to build the HighFlux git client, which is now in available for download.