The idea of writing RFCs for intra-organization engineering doesn't jive with my experience of needing to hack out prototypes to come up with good solutions to problems. Writing a huge RFC before writing code seems to be something that should be the exception not the rule. How do you balance this?
For protocols or standards RFCs are a natural fit because they are about mutually agreed upon communications and formats -- its self evident they must be based on consensus since the consensus itself is the core of what delivers value. Many software development tasks (including examples given by the author) do not have the characteristic of necessitating consensus so requiring RFCs seems to be a trade-off between consensus and other important things like velocity or iteration cycles, not essential complexity to solving the problem.
I wouldn't think that an RFC would have to come before hacking out a prototype. In fact, doing a prototype is probably a great way of preparing for writing an RFC.
I think the author is using RFC not to strictly mean, "IEEE Standards Doc" but more, "a description of the problem you're solving and why also open for comments". I guess in my experience shipping code gung-ho is great for about a year maybe two and then you really start getting to a point where every engineer just cakes their own great ideas on without a technical blueprint of what the company is actually building. Maybe that can be addressed by better technical management, but also in my experience technical managers are not great at conveying overall architecture and context (and perhaps it's not really their fault if non exists in the first place--but that's exactly the problem). I agree you're making a trade off but I don't think it has to be as hardcore as a 20 page specification for IPv10. A small startup with a few engineers can share contex and vision just fine.. until they can't. And the big win with RFCs is you put tribal knowledge down on paper up front instead of post facto.
I think the main point I'm trying to make is that RFCs are a way to capture technical intent not just product requirements. It's not enough to just keep adding features whenever product asks for them (which is always and in a volume that's more than than you have time to do). You shouldn't have to get to the point where the thing or the business is going to fall over to get engineers to agree to build responsible software or refactor that shitty thing to actually work properly. I think RFCs help frame building software in an engineering-driven-but-product-inspired-and-business-context-aware way. That's how I want to work, anyway, but what you get with product-driven sprints is product-gets-their-way-and-business-context-is-solved-with-more-funding-for-that-aws-bill-and-for-more-eng-resources-to-build-more-product-value-so-you-can-charge-more-for-the-product.
Prototypes and RFC can go hand in hand or RFC can be later in the process. I don't think it's either/or choice. The example problem author gives is that someone built something but hasn't communicated across the team. As he points out the list of issues, consensus is the least (3rd - "Someone made an important decision on behalf of our entire team, but the team wasn’t included in it") of the worries. As someone pointed out in the thread it is "Request for Comments" and not consensus. It is fine even if comments are ignored by the author.
It is never fun having to find out something has changed only after production release or later down the line.
An RFC doesn't have to be huge. Even one that becomes huge doesn't have to start that way, and probably won't. As the article points out, intra-organisation work isn't the kicker here in itself - inter-department work is where the concept has merit.
For protocols or standards RFCs are a natural fit because they are about mutually agreed upon communications and formats -- its self evident they must be based on consensus since the consensus itself is the core of what delivers value. Many software development tasks (including examples given by the author) do not have the characteristic of necessitating consensus so requiring RFCs seems to be a trade-off between consensus and other important things like velocity or iteration cycles, not essential complexity to solving the problem.