RFC is not a Design Document
RFC or Request for Comments is a formal document from the Internet Engineering Task Force (IETF) that contains specifications and organizational notes about topics related to the internet and computer networking, such as routing, addressing, and transport technologies (ref).
Many Engineering teams start adopting RFC as a means to get ideas flowing around the organization. The terms are being adopted due to the fact that the early internet community relies on continuously flowing ideas that no one can dictate or mandate. All ideas are open for feedback, thus it is explicitly named RFC.
Before getting into the explanation, let me introduce my background first. I majored in Software Engineering back in my bachelor's and master's degrees. I learn the challenges and strategies of Software Development on how to make the right system, how to make it right, and how to make it fast given budget, timeline, and scope constraints. After the system is built, the system need also be continuously maintained and iterated. To achieve this, my and my team create a design document before we jump into implementation.
Design Doc vs RFC
I stumbled upon an article on how many companies use the term interchangeably. Also kudos to the author who perfectly summarized how each tech company uses written medium to guide their project implementation. As a summary here is the state of both terms that I have collected:
- Design doc interchangeable with RFC — poses minimal risk
- RFC only — poses risk due to no official recognition of how implementation details carried out in the organization
- Design Doc only — poses no risk, since RFC could be not being formalized
- Design doc and RFC coexist — chef kiss
My writing here is dedicated to organizations that adopted either 1, 2, or 3 above.
In an organization, we need to distinguish 2 types of Ideas that float around. There are ideas that are big, bold, ambitious, and abstract. There are also one that is detailed, pragmatic, quantified, measured, and constrained. Let’s call the former Type 1, and the latter Type 2.
Type 1 ideas are great because:
1. They make the company provide more opportunities for work or improvement
2. They make exchanging ideas among people fun without being afraid to be turned down by others
Type 2 ideas are great because:
1. They make us stay connected to details
2. They make the idea implementable within a certain period
3. They make the impact on human visible (such as operational or training need to be done after a project got implemented)
The enemy of Type 1 ideas is early commitment. In order to be committed, Type 1 ideas need to be converted into Type 2 ideas by stress-testing them first. In today’s tech world, we can leverage RFC for this purpose. Before committing, let’s open the discussion to everyone who has the same concern. Try to propose ideas to the people who have control.
If many people have approved our proposal we can safely commit the ideas. Later on, the people who have control still have homework detailing the system under design, thus we use Technical Design Document (or Design Doc for short).
By using the explanation above, both RFC and Design Doc by definition are different and can co-exist. Here are the differences between RFC and Design Doc:
If we dig more, we can see that by nature RFCs fall into the problem space, while providing a little more touch to the Solution space. Meanwhile, the design doc falls into the solution and implementation space. RFC can be benchmarked with PRD (Product Requirement Documents). Some notable difference is PRD is mainly created by the Product team and has control over the system as well (through their engineering team counterparts). Both still need to be committed before being followed up in the form of a Design Doc.
You can read more here on how we come up with Problems, Solutions, and Implementation Spaces. I also reserve future writings on my take on how our design doc can be structured.
