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.
Folks with big titles will always write comments that sound smart and thoughtful but in reality hinder the process. For example:
- This architecture binds us to AWS. Have we estimated the engineering effort to remain cloud-agnostic in case we need to move to Azure next year?
- I see we're using Postgres. Have we considered how we’ll handle horizontal sharding if our user base grows by 1000x in Q4?
- This synchronous API call introduces tight coupling. Shouldn't this be an event-driven architecture to handle back-pressure?
All sound like things that are easy to ask, sound prudent to management, but are impossibly expensive to answer or implement for a feature that just needs to ship.
They only hinder the process if you treat them as demands instead of questions or comments. The questions are generally smart and thoughtful, just often mistimed/misplaced for where most companies decide to have the RFC process (i.e. often after completion rather than before starting main implementation).
It's alright to answer "No, we haven't done estimations for cloud-agnostic architecture as part of this project since it was not part of the approved goals and requirements. If we decide to go multi-cloud at some point in the future, this architecture will need to be reviewed with the rest of the infrastructure as part of the migration plan".
If that kind of answer creates a problem then the issue wasn't really to do with the RFC or the comments, that's just where the other issues in the process became apparent. Namely, the requirements are being set without all relevant stakeholders involved or even aware (which is not the same thing as agreeing).
Agree 100%. I dont see how this is any different than PR review. There is nothing wrong with "no, thats out of scope for now". If the argument is that this answer causes problems, then yes thats an organizational issue. But fundamentally, those kinds of questions are exactly what you should hope to get out of this process by looping in others. A higher level and greater diversity of perspectives.
I find that it's common for small groups to find themselves in a self-reinforcing purity spiral where they are afraid to say "No" to such comments, and they have no role model to get them out of the bad local minimum.
The main difference with PR review is that code is tangible and real and carries more weight than a document full of plans and ideas. There is a broader acknowledgement of the cost of changing working code, but that price-sensitivity seems to evaporate when it comes to RFCs.
Again, I think you are assigning too much importance to comments/questions in the RFC. Yes, there is probably an expectation that a comment/question is _acknowledged_, but I disagree there should be an expectation that it is _resolved_. The same as a PR.
If in a PR I left the comment that 'This architecture binds us to AWS. Have we estimated the engineering effort to remain cloud-agnostic in case we need to move to Azure next year?", it would be bad form for you to ignore the question and merge. It would be totally acceptable to either say "no, I didnt take that into account and I think its out of scope" or "yes, and that will be tackled separately". And it should always come with a consideration that there might need to be more information added to the PR, eg adding clarifying comments to the code.
If you're making a proposal, I feel like an RFC carries a lot more weight than a slideshow or an email. If you really don't need feedback or approval from anyone, sure, go it alone. But if you do need or want to run it past someone, let the document you send them reflect the amount of thought you've put into it, and then maybe they'll hesitate before going off half-cocked & suggesting some idea you already considered.
The folks with big titles need to determine if the company's technical strategy is cloud-agnostic and whether 1000x growth in Q4 is a legitimate concern.
If Big Title wants to own the schedule impact they can make these demands.
Maybe I'm not read into the secret deal with Microsoft for next quarter that'll require all 3 of these.
I would open a new bug for each of those questions and say “we will evaluate this after the MVP is implemented”. Give the person credit in the bug description. That will usually satisfy their concerns. Set the priority on the bugs to low and I’ll never even have to look at them again, unless one of them actually becomes a problem.
Maybe, but also having those hard conversations and delivering a well-scoped project on time will probably overcome any minor butt-hurt from being told "no".
Most people don't mind the being told "no", they just want to understand why and how that might affect them as part of that. For anything but very simple questions (like "do I need to change anything about the way we do CI for this" -> "Nope!") you'll want more than one word to accomplish that communication.
I think when most people reference saying "no" they are really referencing saying "no, %{backgroundOfWhy}" or similar often in a few short sentences, and that's great for everyone all around. It's just the literal "no" with no effort to engage or care about why they are asking that will leave a black mark of "Joe Schmoe is really great at delivering... when he feels like talking to you about things".
They're looking for the level of answer you might get instantly from an llm. I think figuring out the right balance of "ask chatgpt", critical thought, and ownership in these situations is going to be tricky.
In part because of the drive-by questions, they also often force waterfall-like design: few like the answer to their question being "idk, we'll find out when we get there".
So rather than a lightweight doc that looks for obvious gaps, it becomes a giant playbook for every eventuality. While the company claims they're being "agile".
I feel this tension, but I think something has gone awry if people feel like every comment has to be addressed to everyone’s satisfaction. Comments are not commitments, and commenters don’t have an equal stake in the decision—they certainly don’t own the decision, and it’s okay to disagree and commit.
It’s also probably worth being explicit that there is a cost to inaction that can exceed the costs of building the wrong thing. A year or two ago I was lead on a project where we didn’t know the answer to a big ambiguous problem—we just didn’t have a good way to get the information necessary to make the right decision—different people had different ideas about what we should do. So we identified the smallest thing we could build that would be useful such that we could get more information from real world use, knowing full well we might have to rebuild something else from the ground up. And we did! But we were able to get the confidence we needed to build the right thing later! And we got there much faster than if we had tried to deliberate and speculate about what that thing would be.
Also, in that saga, one engineer in particular was really adamant that we address his particular set of concerns. He was unable to disagree and commit—he was kind of religious about all concerns being addressed before moving forward with anything. He had a very difficult time understanding that the RFC process existed to meet business goals—the business did not exist to slot into his ideal RFC process. He is no longer with the company.
You don't really want company wide consensus on every point in the RFC. That should be reserved between the author(s) and their immediate teams. Setting/allowing the expectation that any comment made will be reviewed and responded to until everyone is in agreement about it is going to make things miserable for everyone and improve nothing.
I.e. that culture of pragmatism needs to be defined as part of the expectations process, not an unspoken promise between coworkers. No process is perfect but a footgun process is easy to make anyways.
In my organization we have RFCs, PRDs, ADRs etc. and I would say that the process is fairly broken. That said, I think what you mention is an important but not the only failure mode of a proposals process.
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.
Have you worked at an organization without RFCs, ADRs, etc? The alternative is really just the wild west and whatever politics or pull a person has. RFCs and ADRs are good in the sense that they document _something_ even if the document is junk it's better than an assumption.
Really though it's the organization (and people) that makes or breaks anything.
I generally agree that it's better than nothing. That said, it's possible that sometimes these processes become bureaucratic shields for avoiding certain processes.
For example, a broken RFC process might be a way not to actually involve and gain useful consensus from people (I.e., I did my presentation during the weekly session, nobody had feedback), which instead would be the natural way in a company without that process.
100% agree that it's all about the people (and the culture shaped by them).
There is no perfect process. I think after a long time working in software I now understand that it works like this: you need one person to work by themselves really really quickly to ship and create the foundations. After that, they need to remain in place to make sure the design continues to make sense as more people add code to the monolith. Having a specification process is a must in complex environments, and the downside is that it adds friction (and some people can abuse the back and forth to prevent you from landing your design changes), so you need that process to happen as late as possible. But if you're running in production in sensible environments then you will need to make that process happen earlier than desired.
> you need one person to work by themselves really really quickly to ship and create the foundations
This is literally the secret of every successful project I've worked on. An individual, with high agency and low communication overhead has either been trusted to take the task on themselves, or they've done it secretly to side-step the approval process and organisational overhead. When the foundations are in place it's relatively easy to add engineers, but starting something from scratch with a bunch of people? doomed before it starts in most cases imo
> This leads to authors having to re-explain their thinking in detail
What I like about RFCs (or similar documents) is the ways they work to prevent this. Recently I was involved in planning an initiative without a document like this, and we had to keep explaining and re-explaining the motivation for our decisions to stakeholders and higher-ups. With a document (assuming everyone reads the document before giving feedback), most questions get pre-empted; the ones that don't only need to be addressed once, because the answers end up in the version of the doc which you show to the next person.
Certainly I think it's worth being selective about who you're soliciting comments from, to avoid a too-many-cooks situation, but rare is the project that doesn't need anyone's approval or feedback. Presenting a big fat document gives a sense for the amount of thought that has gone into the design, which quells the kind of off-the-cuff "why not X?" comment you might get in response to a boxes-and-arrows chart and a high-level summary.
My take is that an RFC should be very early in the engineering process, like as part of a proof of concept phase, and should not block progress towards completing a design proposal. The design proposal should list any legitimate alternatives to overall or component designs discussed during RFC along with the reasoning for not using them in a "designs not chosen" appendix. This at least gives your engineering leadership an opportunity to evaluate the general design ideas before anyone is prepared to die on the hill of those ideas.
Architecture / Design review happens post proof of concept but still before any significant development work and major action items are blockers to beginning development. Further discussion about designs not chosen can happen here, especially when a flaw is uncovered that would be addressed by one of those not chosen.
> 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.
IMHO there should be no gaps like that. If you already thought hard and long about these problems, why not just write all your knowledge down, so other people can benefit from that? Also, this makes your work a lot more accessible to those who came after you. Of course, you have to assume a certain baseline of knowledge. But if you already have a good understanding of the problem, why not formulate that as part of the RFC?
It is impossible for people to write all their knowledge down, there will always be gaps, there will always be things taken for granted.
The point is that the author thought that they had captured enough information in their original draft - they can expand on that draft of course, but that's the issue - the task of writing the RFC can become much larger than just trying something out and getting real data.
Like many things in dev it sounds sooo good on the surface, but is a minefield in practice (Brandolini's law + The Iron Law of Bureaucracy for starters).
I'd only advocate it in a very carefully curated team.
> 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.
There's nothing wrong with this. Being able to explain your thinking in detail to someone that doesn't necessarily understand the problem is a pretty good exercise to make sure you yourself fully understand the problem _and your thinking._ Of course, this can't turn in to a lecture on basic things people should know or have looked up before commenting.
Sure, now imagine answering 10 different people to all of their questions? It's the largest hindrance I have ever seen but I agree with the above comment that it largely depends on the team.
Yeah I think it all boils down to culture. Tools like RFC (and anything else) can help propel a good culture forward. But you can't fix a broken culture with a tool.
This is my experience as well, the RFCs turn out are being made for internal processes and policy making. And also I have the feeling that people are making it like Request for Approval for technical changes, so we have to take significantly more time on the RFCs than the real work.
I haven't heard about Alchemy before, but from skimming their docs it looks like Terraform/Pulumi in code form where you explicitly configure infrastructure. Whereas with Encore, you define what you need directly in your application code (databases, pub/sub topics, cron jobs as type-safe objects), and Encore handles provisioning across all environments. Plus you get local development tools, distributed tracing, and automatic API documentation out of the box. The key difference is the toolbox you get + the fact that you're writing application logic, not infrastructure config.
I've only really used AWS at a startup, but this sounds kinda scary based on that experience just because it's so easy to configure services in AWS to cost you lots more. How does something like Encore figure out what to use for the nitty-gritty AWS config details without exposing the user to those decisions? I can't remember any really specific examples because it's been a while since I used AWS, but a smaller example would be something like configuring logging/time to keep logs.
Encore uses sensible defaults optimized for cost and performance (eg. reasonable instance sizes, log retention periods, backup schedules), but you have full control to modify anything. You can adjust configs per environment through the Encore Cloud dashboard or directly in your AWS console - it's all standard AWS resources (RDS, Fargate, etc.) in your account.
The goal is to start with good defaults so you don't have to think about every config detail upfront, but nothing is locked down. You can also set up approval workflows for any infrastructure changes that have cost implications before they're applied.
No, on 15 April 2023 the RSF suddenly attacked SAF bases and tried to assassinate al-Burhan, SAF leader. That's a stark escalation just like how Oct 7th. happened to Israel, where both had simmering issues.
the issue with JSONPath is that it took 17 years for it to become a properly fleshed-out standard. The original idea came from a 2007 blog post [0], which was then extended and implemented subtly differently dozens of times, with the result that almost every JSON Path implementation out there is incompatible with the others.
if you're going to hold Framework to that standard, wouldn't you also agree that buying a Lenovo machine would be indirectly supporting an authoritarian government with a troubling human-rights record?
You're typically not buying a Framework just because you like the hardware. Framework represents a political project, so you typically buy Framework because you support their values and politics. I don't.
You can rationalise your decision however you want, but to me it sounds like you're mad with the little guy for their lack of moral purity, but you're implicitly fine with a larger company doing much worse. That seems inconsistent at best.
You may find it inconsistent, and that's fine. But I do actually find it worse to buy from the explicitly political pro-fascist company than to buy from the "normal company" which just "incidentally" benefit fascist governments through their normal business operations.
So in other words you've got nothing? There is literally nothing in your links that backs up your claims.
So conferences in every western country should also not invite Chinese or Japanese speakers because they hold similar views to DHH? I'm so over this exhausting need to feel self-righteous.
International trade is extremely complex, funding and publicizing a project is not. Framework supports DHH, both financially and in terms of publicity. That's not something I wanna support.
The mental gymnastics and contortions you are putting yourself through are quite stunning. You're finding associations that do not exist. I feel I'm staring at a wall strewn with thumb-tacked red yarn, linking all sorts of nonsense together while the creator steps back and exclaims "see, proof!".
Framework makes hardware and software. If you're going to close yourself off to any product or organization that happens to have some users you disagree with - then you're not going to get very far in this world. This is a wild, and frankly unhealthy perspective to hold.
Please explain which associations I'm finding which do not exist.
> If you're going to close yourself off to any product or organization that happens to have some users you disagree with
I do not see where I mentioned Framework users. I care about the actions of the company. I care that they decide to support DHH, financially and through promoting his projects, and I care that they double down on their support in the face of push-back.
> double down on their support in the face of push-back.
Because the push-back was dumb. This idea what we have to isolate and attack every person that we don't agree with is dumb. That you consider DHH's position on immigration sufficient to label him a fascist is dumb. All of it is moral showboating with no actual substance, otherwise you'd put your money where you mouth is and not purchase from most companies in the world that work with actual fascist regimes.
Your claim was that they explicitly support fascism. That doesn't seem to be the case at all. What you seem to mean instead is: They financially support a popular open source project called Omarchy, which is built by DHH, and you believe DHH to be a fascist.
You're welcome to your opinion, and I have zero insight into whether DHH is a fascist or not, but by no means is that explicit support for fascism! It's not just exaggeration, it's actually a lie.
If you buy a machine from Framework you might indirectly support a project which is maintained by someone whose opinions you dislike.
If you buy a Lenovo machine you will contribute to the revenue of an authoritarian government that will use some of that money to perpetuate human rights abuses against its own citizens, and maybe the citizens of your own country too one day.
Which is the most moral choice here in your opinion?
I mean I already answered that, didn't I? I find it worse to buy from the explicitly political pro-fascist company than to buy from the "normal company" which just "incidentally" benefit fascist governments through their normal business operations.
To exaggerate, we could imagine that there was an explicitly nazi computer manufacturer who put swastika stickers on their laptops and everything. When faced with the choice of Lenovo and this explicitly nazi manufacturer, I would probably choose the Lenovo, even though you could probably do the same consequentialist math and conclude that Lenovo does more actual harm through their utility to the CCP than what the tiny nazi computer company can do. I imagine you feel the same way.
What Framework does is obviously way less egregious than my hypothetical example, but I'm still not comfortable associating with a company which so publicly funds DHH, for the same kind of reason that I would not be comfortable associating with the nazi computer company.
Thanks for bearing with me, I am sincerely trying to understand your mindset here.
So this is really a signalling thing? If you bought a Framework laptop you'd be signalling to your peers that you're ambivalent about supporting an ideology that obviously you fundamentally disagree with and is unanimously despised within your groups?
By buying a Framework laptop I'm signaling to Framework that I don't care about their support of the ideology. My ideal outcome here would be that Framework's support of DHH would directly and unambiguously result in a dramatic loss of sales, which would signal to the world that supporting such ideologies is toxic to your brand.
And, sure, my peers play a role too. What message do I send, for example, to my transgender friends when I demonstrate that I don't mind Framework's public support of DHH's public transphobic rhetoric? What message do I send to my non-white friends when I demonstrate that I don't mind Framework's public support of DHH's public "the UK was better when it was all white" rhetoric? Et cetera.
I don't know... As someone who many people would characterize as "way too woke", this doesn't really quite ruin Framework for me (though I don't own any of their products).
DHH is certainly an ass, and this is my first time reading about the racist stuff (before this I just found him generally extremely unlikable), but just general association with someone with shitty opinions doesn't fully ruin a project for me. I guess Omarchy is popular nowadays (I'm really not sure why, if someone really knows, please explain), people are going to want to use it on their Framework computers, ergo: Framework has a reason to cooperate with Omarchy developers so their devices work like the customers want them to, and I guess I'm fine with it even if DHH leaves a bad taste in my mouth...
I guess I sort of feel similar in regards to suckless, I don't really like most of their projects, from what I've heard there are some abhorrent people involved, but I wouldn't really put blame on the distro maintainer that packages their projects for their users to use, I guess?
Though, I definitely get why people might feel differently.
I don't use Bluesky, I prefer Mastodon and frankly quite dislike Bluesky's faux-decentralization. But Framework uses Bluesky, so that's what I'm gonna link to when I wanna link to their posts.
Not really: nations state level actor: a hacker group funded by a country, not necessarily directly part of that country's government but at the same time kept at arms length for deniability purposes. For instance, hacking groups operating from China, North Korea, Iran and Russia are often doing this with the tacit approval and often funding from the countries they operate in, but are not part of the 'official' government. Obviously the various secret services in so far as they have personnel engaged in targeted hacks are also nation state level actors.
reply