Yes we should rewrite it in language Y if everyone on the team is comfortable with the language, it provides nonfunctional benefits, and has potential to drive business value.

It’s just about acknowledging the conditions that would make an idea a good one. All ideas are good in a specific context. Instead of assuming everyone’s aware of the current context, state the ideal context for an idea.

But just as ideas exist in a context, so does the decision. If your team (for example) doesn’t have everyone know the language, then “yes if (false)” is just “no”. Businesses move and conditions change so keeping this “no-go” idea around as a “yes if” just means that people will try to resurrect it later. It may be a spurious idea, but you’ve given it a false blessing by attaching a conditional approval.

"Yes if you can solve the halting problem" is better than a "no". It's "no, and there are mathematical proofs why it will never be a 'yes'".

More realistically, you're more likely to hit "yes if there is compelling evidence that $choice is better than $status_quo with respect to $criteria". Sometimes that sort of evidence is expensive-to-impossible to demonstrate such that it's basically a "no", but again, it's a much more specific "no".

I'm all for positive language and this sort of feedback. But one needs to keep in mind that this sort of setup can lead to a lot of Yak shaving. So there should be somewhere/someone in the process that addresses the value vs Yak shaving costs.

That's just roundabout way of saying "no because we don't have experience in Y language"

> What if someone proposes "we should rewrite X in Y language,"

Yes, if 50% of our development team is proficient in Y, X is a bottleneck or EOL, rewrite will solve significant problems.

> we should use Z database instead.

Yes, if Z is widely used in our stack, Z will realize advantages that cannot be achieved with the current database, Z is required to solve upcoming problems.

That's how I take it, at least: You shouldn't say "No," you should say "this is why not."

The "no" is bc challengeable reasons, which are useful to be explicit about

"This would take resources away from delivering X and limit devs ability to collaborate, so we need a way to motivate the budget precedence / growth and a way to afford 50% + 6mo per dev productivity hit around retraining"

"Database x is a VC co toy that risks dying, acquisition by Oracle, and losing customer data when we do not have time for self-inflicted nonsense. We need ways to mitigate the risk such as $10M in NIH DB dev budget in case the likely case happens. We already spent our innovation budget for X, so need more to motivate doing it again on Y."

Less than gate keeping, this is a great way to help mature early/mid career devs / job hoppers who haven't had the chance to live with many self-inflicted senior-level mistakes yet

The above comment is a good example of non constructive ways to say no.

Anybody could reject any RFC with the reasons you gave (especially with the vague “bunch of other issues” catch all).

So I’d say, yes, you can say no, if there’s specific, written down, largely agreed upon principles or goals. The thing is, when a no is in reference to specific principles and goals, it’s no longer a no. It’s a “yes if it fits with XYZ. Can you explain how this works because I can’t see it.”

If it’s a no in reference to vague reasons, it’s just gate-keeping. I suppose I can say yes to gate keeping if you can find a way to be encouraging to the RFC author and value the efforts and thinking that went into it. Otherwise gate keeping breeds frustrated complacency.

>If it’s a no in reference to vague reasons, it’s just gate-keeping.

What if it is yes with vague reasons? Why "yes" should be easier than "no" ? It's potentially extra work and extra code to manage. If something is vague in it's usefulness enough that it doesn't get yes with good reasons it should probably go back to drawing board

"This proposal is vague in its usefulness" is the same thing as not adhering to specific, written, agreed upon goals and principles. So you could say "yes if this becomes more specific in relation to X".

However, this situation can also easily arise where the goals and principles are vague, and in that case it's ultimately means that its more of a vague reasons to say no than a vague proposal.

The "it's potentially extra work and extra code to manage" is, imo, another wildcard vague reason to say no. It can be used to deny essentially any proposal anybody makes. It's Machiavellian. In a cooperative teamwork oriented environment, those things are given budgets so there can be some wiggle room for each proposal to progress.

I get your point, and they do address this later on in the piece kind of. It sounds like it's perfectly valid to say no, especially after reviewing the document and their architectural meeting where they discuss it more in depth. But they're also not trying to actively encourage saying no in the document, instead encouraging responses that points to how to get to a solid idea.

So saying "no" isn't forbidden, but it isn't the default either. At least that's my interpretation.

I had the same reaction but thinking more I’m actually kind of surprised by the elegance of “yes/not yet.”

One of the best questions you can ask someone (including yourself) when in disagreement is “what new data/fact/different condition would convince you of my position?” The “not yet” framing kind of sneaks that question in via just two words! “Not yet” implies you must define the criteria by which it turns to a yes.

Yeah. Not everyone who thinks they have a good idea has one, and the way this is structured it's very, very time-consuming to defeat a legitimately bad proposal. It feels a lot like when a conspiracy theorist says "Bildenberg cabal is made of hollow earth lizard people" and your only retorts are "yes" or "I'm not yet convinced".

This is correct. The arguments for taboo-ing the word "no" seem to be rooted in conflict aversion. Powerless people fear pushback and powerful people fear taking a stand.

Its like an Uber rating of < 5 means bad. A rating of "Yes If xxx" means "No"

Yes, if you use the current language rather than rewriting.

Yes, if you use our current database rather than a new one.