Why you should use RFCs
What is an RFC?
RFC stands for Request For Comments and it is a formal document from the Internet Engineering Task Force (IETF). It appeared as the result of committee drafting and subsequent reviews by interested parties until a final form had been agreed on and published. But this might not be of interest to most engineers.
What should be of interest is how this can help a cross-functional team of engineers.
First of all, here are a few examples of what an RFC can be used for:
- reach a system design decision
- define how a cross-functional feature will work
- define how a specific process should work
- agree on what solution to use for an infrastructure implementation
Think of RFCs as technical documents that allow for the dissemination of a feature within an engineering team. They allow for the collection of input and technical verification from all parties affected, such as backend, mobile clients, and data science. Once approved, they are the source of truth and act as a point of reference for the entire team when the implementation starts.
Why should anyone use RFCs?
Surely it’s tempting to say that writing an extra document takes time that an engineer could otherwise use to work on the implementation. But how many times have you dealt with a misalignment between functions, a misunderstanding of how BE and FE communicate, or a realization that new issues aroused due to the use of a less than ideal solution for an architectural decision?
In my experience, these things happen often enough that they should be taken into consideration.
Here are some reasons why it’s worth using the RFC process in a team:
- Demands researching and analyzing potential solutions before proposing one.
- Aggregates expertise and thoughts from all relevant team members. They can challenge the proposed solution, highlight edge cases and make useful suggestions.
- Provides clarity of how things should work to everyone involved, acting as the source of truth.
- Defines a contract between functions (when this is the case), allowing parallel work on BE and clients, thus preventing misalignments and delays.
- Guarantees all details have been laid down before the implementation starts, allowing for a clear and uninterrupted development process.
- Avoids pursuing heavily overlapping work between teams since it acts as a shared knowledge base.
How to write an RFC
There are a few rules to follow when using the RFC process to make certain it leads to a good outcome and has a positive effect on the team’s communication and development speed.
- Use a template. Having the same structure for all RFCs makes it easier to read and find information for everyone. It also guarantees the presence of the main elements. There’s a template attached at the end of the article. It’s meant as an example, as each team can agree on a template that suits them best.
- Make contributing easy. The essential aspect of the RFC is comments, and it should be easy to add, see and keep track of them in the document. Google Docs and Notion are just two good tools for achieving this. They allow you to share and group RFCs together and make contributing easy.
- Assign an author. That doesn’t mean the author has to write everything themselves, but it means they’re in charge of the progress and the completion of the RFC, as well as finding a reviewer and sharing the document with the team.
- Assign a reviewer. Although the document should be open for comments from everyone involved, it’s good to have a main reviewer in charge of making sure the information is clear, accurate, and complete and that it makes sense for all parties. Depending on the scope of the RFC, there may be more reviewers (i.e. one from the engineering team, one from the data science team).
- Good communication. This point is valid for the communication of the proposed solution in the documents, but also for letting the team know whenever the RFC status has changed. If just the author and the reviewer have read the RFC from the initial draft until it has been approved, something is wrong. The author is responsible to share the documents with the team and encourage them to contribute in the right phase of the process.
RFC Template
The template is based on Phil Calçado’s template which I encourage you to read for more in-depth suggestions.
