Patch review is a process by which newcomers and experts debate proposed changes to a codebase–a textual description of how a particular human-created system is to function. In KDE, we use Phabricator for this, but we’re switching to GitLab soon. Both serve the same purpose: to provide a forum where proposed changes can be discussed, revised, and decided upon.

It occurred to me recently that this sounds a bit like the process of lawmaking. Politicians propose bills (patches) that amend their government’s code of laws (codebase) which are passed through committees and hearings (the review process) and eventually get voted on (reviewed) and either pass (get merged) or require revision (go around for updates), or fail (get abandoned).

I’m reasonably confident that there’s little overlap between politicians and software enthusiasts. In my home country of the USA for example, most of our federal government politicians are former lawyers, businesspeople, or educators. “Software engineer” is listed as a “more unusual” former profession.

This strikes me as a shame. While lawyers, businesspeople, and educators are quite unfamiliar with the process of transforming a proposal for improvement on a systemic scale into a permanent alteration of the rules that affects everyone, software people do it every day. Likewise, software people like us tend to have little experience in the political process. We act like we invented patch review, but our governments have been doing it for hundreds of years! The overlap got me thinking: perhaps there is something that each group can learn from one another.

 

Have a constitution

Governments write constitutions to make their foundational principles clear and obvious. That way, everybody knows which ideas are central to the society’s identity, and which ones are off-limits.

Lesson for software engineers: Make your software’s guiding principles, explicit, not implicit. People often figure this out organically, but it’s much easier if your software has a constitution-like document and clearly indicates which features are non-negotiable when it comes to proposing their implementation or removal.

 
 

Don’t neglect trust

If you have a bad relationship with the people reviewing your patch, they will suspect your motives, nitpick your changes, and generally react with low enthusiasm. Even if your patch is a good one, the reviewers’ opinion of it will be clouded by their judgment of you. Therefore, don’t neglect your social relationships and act like a jerk, or else the whole process basically doesn’t work.

Lesson for politicians: don’t ignore or damage your social relationships with your colleagues or else your entire job is a big waste of time. Adopt a mindset that legislation is a collaboration rather than a majority-rules deathmatch or an opportunity to make speeches on a stage. Also, arrive with pure motives. If you’re there to try to tilt the playing field towards your favored groups, the people who represent the opposite side will notice and oppose you at every turn, and you’re likely to have a frustrating and unproductive career full of outrage-filled press conferences but not much real accomplishment.

 
 

Review in stages

In governments, often bills undergo review by multiple committed before they’re presented to the full body for debate and voting. This is good, because it gives a chance for obvious mistakes to be corrected in advance of the final vote.

Lesson for software engineers: use a multi-step patch review process, with relevant experts in control at each step of the way. For example, the big-picture software architects should review a patch for to make sure it conceptually makes sense in the first place; then backend programmers should dive into its technical implementation; the UI designers should go over its user interface, and so on.

 
 

Keep patches small

Large patches are hard to review and fill the reviewers with a sense of dread. They touch many things and therefore have more opportunities to change something in a way that a stakeholder will object to. They often get bogged down in process and conceptual arguments. For these reasons, it’s best to keep patches small and focused, and split a large change into a series of individually-manageable patches that each depend on one another, known as a dependency chain.

Lesson for politicians: avoid 1,000 page mega-bills. If a bill needs to be enormous in order to work, there’s probably a deeper conceptual issue with it that everyone senses.

 
 

Have an institutional memory

Records of how bills are moved along in the lawmaking process are kept meticulously. This preserves institutional memory, so that newcomers don’t make the same mistakes that their older colleagues and forefathers already learned from.

Lesson for software engineers: Keep records of why decisions were made–and even more importantly, why they were reverted. If you move from one infrastructure system to another, migrate all the data so history isn’t lost. This prevents the phenomenon of newcomers who propose the same changes and repeat the commit/regress/revert cycle.

 

Make reversion easy

When a patch causes regressions, it can be reverted. Oftentimes it’s better to fix it, but if the fixes are too invasive or the regressions outnumber the benefits, it may be a better idea to revert the change and try again. Making reversion easy promotes a culture of innovation and experimentation. People won’t be as worried about merging things, because if they cause problems, it’s easy to undo the changes. Change becomes playful and fun, rather than consequential and scary.

Lesson for politicians: Don’t make it too hard to repeal bad laws. When a newly-passed law causes problems in a society, it’s tempting to try to amend it to fix the problems, and sometimes this works. But sometimes it just needs to be re-done from scratch, like a bad patch in software. Being willing to repeal laws that aren’t working defuses tension. That said…

 

Don’t rush

Bills and patches that get through their processes quickly are often problematic, riddled with unseen regressions and unanticipated consequences. This is much less common in governments, because the lawmaking process usually has deliberate safeguards put in place to ensure that a bill is not transformed into a law too quickly before there’s been adequate time for debate.

Lesson for software engineers: Take your time so you don’t push out buggy, regression-filled software. However…

 
 

Don’t make your users live on the master branch

Rushing isn’t such a huge deal as long as you have a QA process and discrete releases. These tools provide time for regressions to be fixed and rough edges to be smoothed out. When patches can be evaluated in a safe sandbox of sorts and subsequently tweaked before their effects are released to users, it’s not so bad to move quickly. But you can’t expose your users to the churn stirred up by a fast process; it needs to be contained internally.

Lesson for politicians: You don’t need so much process surrounding lawmaking if you don’t roll out all approved changes immediately. Before new bills take effect, let them simmer for a while in a “release branch” where they can undergo QA so that regressions can be found before they’re inflicted on unsuspected citizens (users)!

 

As software people, there are lessons we can take from our governments’ successes (and more often these days it seems, their failures), because this aspect of our professions overlaps quite a bit. It also exposes an uncomfortable truth: changing the rules and behaviors of a system that effects everyone is inherently political. That’s why we invented patch review processes: to make sure that important voices are heard, that the system doesn’t become inhumane for people who depend on it, and that its overall trajectory is positive.

Personally I’m a lot more sanguine about the prospect of this in software than government right now, and I think that’s something that needs to change. The efficacy and positive societal impacts of our governments’ lawmaking seems to be at a bit of an ebb at the moment. But there may come a point in time when our experience in patch review becomes useful on a larger stage, and benefits not only users of KDE software, but also the people of the world. We shouldn’t be afraid of politics; our everyday experiences in KDE are in fact the prefect preparation! Far from being distant and scary, it’s something we’re engaging in–and succeeding at–every time we contribute to KDE. I think it’s time for us to become active in applying those lessons to the societies that we live in.