“RFC” stands for “Request For Comments”. It is a document which has three main purposes:
- The most important one is to serve as a thinking tool for its author.
- It also works as a mechanism to share system information among the developers.
- And finally, as the center of the discussion between alternatives.
Once the implementation path is clearer, there is no need to keep the RFC alive. Regarding when to write an RFC… have you ever had the problem of “oh, this team designs too much”? Me neither: developers are more than willing to jump straight into coding that to reflect on what they are going to build. So, I don’t think an RFC is just for big fat cross-cutting features: it is for almost every development that is not straight forward convertible to tasks.
This is my typical RFC template.
Interesting refs
- 🗞️Articles Another vote for asynchronous writing to solve stuff: How to Stop Endless Discussions (candost.blog)
- Here they propose the NABC model for RFCs
- 🗞️Articles The Power of “Yes, if”: Iterating on our RFC Process — Squarespace / Engineering
- 🗞️Articles Scaling Engineering Teams via RFCs: Writing Things Down - The Pragmatic Engineer
- 🗞️Articles RFCs Design Docs at Google (industrialempathy.com)
Subscribing to agile methodologies is not an excuse for not taking the time to get solutions to actually known problems right.
- An example of how to have RFCs in Github: https://github.com/uber/baseweb/pull/532
- On when to write an ADR and RFCs. An RFC may or may not end up in an ADR, which is the decision: When Should I Write an Architecture Decision Record : Spotify Engineering (atspotify.com)