> Another advantage of the document over verbal explanation is that a well-written RFC leaves little room for misinterpretation. It can include diagrams, examples, or calculations to illustrate and support the idea.
> Finally, we can return and reread the RFC later. Human memory is unreliable; already after a day, details that were crystal clear in one’s mind start to get blurry. When these details are written down, it is easy to review them at any time.
‘You have to write things down, because spoken words disappear into the air,’ was one of the first bits of feedback I received in my teacher training.
> The most common objection is that writing proposals is “a waste of time” compared to writing code.
The extra time spent writing is actually spent thinking.
> The extra time spent writing is actually spent thinking.
Common theme for decades is "we can save a few days of planning with just a few weeks of programming".
But then there's the darker realization that sometimes the people you are working for are incapable of reasoning about planning artefacts or understanding how the system will look or operate simply from a document. So you need to present the system in small iterative chunks and repeatedly re-align expectations with reality: Agile.
And sometimes you genuinely need to do exploratory work which doesn't fit into a planning framework - actual research!
> The extra time spent writing is actually spent thinking.
Until someone decides that using ChatGPT to write your RFC is a good idea. Then you get something that looks great, but the person behind the prompt actually understands less.
- Douglas Adams, "Life, the Universe, and Everything"
(It took an unreasonably long time to find this quote!)
Obviously this does't work for all software. But it suits systems with end-to-end behaviour and sequences of actions.
So it's possible to leave it to developers, but expect a high quality spec along with the code.
I am right and my son is right, but his hair is still not washed.
I became a more effective manager and a better father when I learned how to talk to him better.
I also don't get your son's response at all. How is he contradicting you at all and how does that lead to unwashed hair?
I ask my team to clarify requirements better. They say that they already have Jira. It's as if they were implying that the presence of a tool (Jira) should be enough to provide clear stories. But it's not about the tool. It's about them not using the tool properly but pointing at the tool (or process) as an excuse.
I ask my son to wash his hair. He says there is shampoo in the shower. It's as if the presence of the shampoo implies that his hair should be clean. It's not about the lack of tooling, but about the fact that he did not wash his hair with the tool that he had available.
People often blame tooling or methodology, but most often its that they don't know how to use the tooling or methodology well. They will say things like "if we only used X our problems would go away." Most likely, they won't.
I posted a lazy comment earlier because I did not have time to type it out. Apologies.
RE: your work, I would probably fight hard to reduce all the bureaucracy-inviting tools (like Jira). That removes the excuse "we have tools already, why don't we have clear stories?" -- though I am aware that for many people this fight would cost them their job.
This is what user stories were supposed to accomplish in a more lightweight way.
The whole scrum DoR (definition of ready) status means that something is clear and ready for development.
Stories are written and are sent to the engineering team for clarification. This is where the comments are supposed to come in. There is a clear step for clarification of stories, before the story is ready for development. It gets marked as DoR when that clarification is done.
It does not matter if you use RFCs, user stories, or hallway conversations as your process of clarifying work. If it does not work, it does not work.
Any way you can get your teams to communicate more clearly is great.
I've just left a company that used to have an internal RFC process and it was a very significant barrier to progress that stifled innovation, led to breakdown of working relationships and caused the most productive engineers to run for the exits.
RFC is a request for comments, and it turns out you have to be really careful about the kinds of comments you solicit and who from. As soon as you ask people to comment you are setting an expectation that you will take their feedback onboard and address their points, but there’s a real asymmetry here - it is much easier to leave a critical comment, or to ask a question, than it is to address the concerns or answer the question.
This asymmetrical nature puts much more work on the shoulders of the RFC author. Similarly, the people writing the RFC have typically thought much harder and longer and deeper about the problem than the people giving feedback on it. This leads to authors having to re-explain their thinking in detail, covering points that they’d omitted for brevity or because they are obvious to those with a good understanding of the problem.
Suddenly, the task changes from shipping the feature or making the change to achieving consensus on the RFC. I have seen that process take months - far longer, and being far more expensive than just doing the work would be.
The worst part is - no one is in the wrong! The authors write the RFC in good faith, the commenters review the RFC in good faith, and they rightly expect that any problems they identify are addressed. But the whole process can be soul crushingly slow, painful and full of professional conflict.
I’m not saying that RFCs are bad overall, but you have to have a culture of accountability, pragmatism and getting things done to actually make this process work.
In some cases I have seen, people use RFCs to steamroll decisions when they are the only stakeholders. Here the waste comes from the fact that the proposal becomes just a bureaucratic step or a way to diffuse responsibility.
In the case you mention (which I have seen many times) I would say the general issue is that the goals and the constraints are not qualified sufficiently. If that's the case, then there are only 2 cases: there is an objective way to measure if an objection or comment makes sense or not, or it is subjective. If it's objective, then consensus is easy to reach, if it's subjective, it needs to be acknowledged and usually the decisions falls on those who are responsible for the outcome (e.g., the team who needs to maintain or build the thing).
Of course, the debate can move to constraints, goals or even ways to measure, but these are generally more straightforward.
I got this idea from Netflix's founder's book "No Rules Rules" (highly recommend it)
Overall, I think the main idea is: context is what matters, and RFC helps you get your (mine, I'm the founder) vision into people's heads a bit more. Therefore, people can be more autonomous and move on faster.
https://productstrategy.co/working-backwards-the-amazon-prfa...
pstuart•5d ago
That said, a ticketing system should ostensibly offer this same effect, but in my experience they're often populated with brief titles and maybe a short paragraph on expectations.
romannikolaev•5d ago
In other cases, it can be very tactical. I think you are right, probably it can be expressed directly in the form of a ticket. The discussion well happen in the comments to the ticket in this case.
pstuart•5d ago
Anything that will prompt stakeholders to engage and clarify expectations is a win. It's hard to make this happen even when everybody is philosophically aligned on the need to do so, so reframing it as an RFC could be quite the useful "One Weird Trick" ;-).
observationist•5d ago
swiftcoder•47m ago
If the ticketing system were private to the engineers, it probably would serve the same purpose. But inevitably ticketing systems have wider visibility, and become a mechanism for signalling progress to management/product/sales... at which point engineers are actively incentivised not to put actual data in the ticketing system