So you don’t feel like writing an RFC? Here are four reasons to do it anyway

Writing an RFC is a great way to improve your designs and to make better decisions. Over the years, I’ve written dozens of RFCs and every one of them turned out to be invaluable. Unfortunately, writing an RFC always costs me a lot of energy. As a result, I write less RFCs than I probably should.

After talking to a few of my colleagues, I’ve learned that I’m not alone with this problem. Several people admitted that they would like to write more RFCs, but struggle to do so as well.

In this article, I’ll try to motivate my future self to actually write an RFC. Hopefully, this can be of use to you too.

What is an RFC?

I should probably explain what an RFC is, just in case you haven’t come across this really useful tool yet.

An RFC, or “request for comments”, is a kind of document used to capture your thoughts, to propose a solution to a problem and to involve others before making a decision.

RFCs come in all shapes and forms. But typically, they are relatively short, begin with an introduction and often include images, charts and comparison tables.

RFCs can be incredibly valuable for a number of reasons. So let’s talk about their benefits.

RFCs serve as documentation

In an ideal world, our software systems would all be perfectly documented. The best documentation gives you a high-level overview of the system, mentions the tradeoffs that were made and articulates some design intent. All this information is invaluable when you are just starting to work with a new system.

Unfortunately, I don’t encounter that kind of documentation very often. Instead, teams typically rely on their own experiences from working with the code and ad-hoc explanations.

In a team that is small and stable, an approach with little documentation can work well. But if that team starts to grow or to change in any other way, all the tacit knowledge can get lost. Once that has happened, the original design intent is often lost.

If you find yourself working on such a system, RFCs can be a good substitute for documentation. Although the content in an old RFC might no longer be up-to-date, a lot of it might still be relevant.

RFCs lead to better outcomes

Once you’ve got all your thoughts written down into a comprehensive document, there’s another benefit: you can share your analysis with others.

And I’d really recommend that you do so, because the feedback and ideas of others will often help you to find better solutions.

If you can, try to involve domain experts from across the company that might not know about your project yet. Are you working on a project related to compliance? Or perhaps on improvements to your service’s observability? Or on some browser performance improvements? If your company is large enough, chances are that someone else can share some valuable insights with you.

But even if you don’t have any domain expert available, you’ll still benefit from another pair of eyes. Your peers will be able to bring in their own experiences and give you new perspectives. Does your project really need to be build in this one particular way? Or is it even necessary at all? Are there any shortcuts?

My work has benefitted a lot from interacting with others and writing an RFC has often been a great first step to get feedback.

RFCs drive alignment

Many decisions are made in meetings. Once a meeting is over, people generally assume that everyone is on the same page. However, this is rarely the case. In reality, everyone’s got a slightly different understanding of what was discussed in that meeting.

What started as a simple misunderstanding at the beginning of your project can easily transform into a costly conflict towards the end of it.

To avoid situations like that, we should try to detect gaps in understanding and alignment as soon as possible.

RFCs are a great tool to do just that!

Once you’ve got your own thoughts written down, you can share them with your colleagues. This gives them an opportunity to compare their thoughts with yours. If they spot any misalignment, they can reveal it relatively early in the project.

RFCs add structure to your thoughts

Think about a problem long enough, and your mind will fill with lots of ideas and thoughts related to the problem.

Although all these thoughts are interconnected, they are poorly structured. Instead, you might feel like you’re holding this messy ball of string in your head, one where several different kinds of string are interwoven and all tangled up.

When your mind feels like that, many of your best thoughts might be inaccessible. Trying to chase a particular line of thought might just make you walk around in circles. Or, to put it in a different way, you’re stuck and seem to no longer make any progress.

In situations like this, writing an RFC can help you to untangle all your thoughts. When you try to explain your thoughts to a reader, you are forced to structure them so that someone else can understand them.

That structure can not only help you to get unstuck, but also makes it possible to discover new ideas and to discover gaps in your previous analysis.

Time to get started

I hope that I could convince you about the many benefits of RFCs and that you are just as keen to write your next one as I am.

And don’t worry: your RFC doesn’t have to be perfect. Perfect is the enemy of good. Just aim for “good enough”.