Hacker News Reader

Comment by mohsen1 | Hacker News Reader

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.

View on HN

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.

My favorite response to the unexpected "have we considered" questions are "no". I'm telling the truth, and often there is no follow up!

That does not reflect well on you, and these people may be on your promotion committee.

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".

that's not how humans work

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".

Reply on news.ycombinator.com