Why questions about "the correct way" are too broad

Question

Questions of the following form are often closed as too broad:

1. "Review My Design"
2. "What is the Best Practice?"
3. "Will my approach work? Is it viable?"
4. "Is this the correct / preferred / accepted / most popular / better way?"
5. "What could go wrong?"
6. "Tell me the name of this thing so that I can Google it."

How can I avoid the problems associated with these kinds of questions so that my post isn't closed as Too Broad?

Related
If there are two ways of approaching a task, how should one choose between them?

Answer 1

Ask us about your specific problem.

Focus your questions on a specific, design-related problem you are having. Instead of asking "Is this SOLID," show us part of your project, tell us why you think it's not SOLID, and ask us how you can make it more SOLID.

State your criteria.

Questions asking if something is a "best practice," without also clarifying your specific objectives, are not answerable. We don't know what "best practice" is for your project unless you tell us specifically what you want to achieve. Restating the question as "most correct" or "most widely-accepted" doesn't work either. Tell us what you want your project to accomplish, so that we can determine what is "most correct" for your project.

Be specific.

Your questions must be specific. "Review my design" isn't answerable here. A good answer to such a question is going to be too long to fit in the answer space. Ask a more specific question like "How do I properly communicate between aggregate roots?"

Focus on requirements.

We don't know what "correct" means for your project, unless you tell us what your project is supposed to do. Global variables are generally frowned upon, but in some projects (like games), they are unavoidable. Ask about your specific requirements, and how you can best achieve those.

Veracity, not vocabulary.

Word definitions are useless if you don't understand the underlying concepts. Instead of asking for a word or a concept, tell us what you want to achieve, and ask us how you can achieve it.

Answer 2

Lest people see this post and think the expressed opinions are a universal consensus of this site's users, I wanted to provide a dissenting opinion.

Software engineering is a challenging field, and people have questions at all levels of abstraction of the design process. A good answer writer adjusts to the level of confusion of the person asking the question, instead of expecting the question to adjust to the kind of answers that are easier or more fun to write. Good answers can and are made to the above-mentioned types of questions, in the short space before other people vote them as "too broad to possibly answer."

This site is supposed to be much more about general principles rather than specific applications like StackOverflow. We don't go around telling college students, "Well, I could teach you about when to choose insertion sort, but I don't know what your project would use it for." It's okay to be a little abstract here. Programmers are allegedly good at abstraction.

While I object to the leading and stereotyped wording of the example questions, I think they are in general a reasonable fit for a site that purports to be about "software development methods, practices, requirements, architecture, and design."

1. "Review My Design". Design is right in the site tour. It's one of the main purposes of the site. People don't always know they best criteria by which to evaluate a design. If they did, most of the time they wouldn't need to ask the question. If they don't provide criteria, answer writers should list their own criteria, and state under which circumstances they would or would not be applicable. Most software design principles are not hugely situation specific. If you think you need context to answer, just say why the context matters.
2. "What is the Best Practice?" Again, practices are right in our tour. A practice is not usually best under all circumstances, but it is not that hard to state the limitations. We don't need one-word definitive answers. If the answer is "it depends," tell me what it depends on.
3. "Will my approach work? Is it viable?" Again fits under design. If you can't tell if it is viable from the question, state what information you would need to gather. State some alternatives that might be better. The question isn't asking for a contractual sign-off. It's asking for a second opinion about if anything major was missed.
4. "Is this the correct/preferred/canonical/idiomatic/accepted/most popular way?" Sort of the same as the best practice question. Software is written for other humans to read. Part of that is writing it in the way other humans would most likely expect. The best way to find out what other humans expect our code to look like is to ask them.
5. "Tell me all of the things that can possibly go wrong." Software is full of non-obvious gotchas, things that look correct but aren't. Asking someone with experience in that area to help avoid the worst problems is one of the most important reasons for asking questions. It's the main thing I wish my coworkers would do more frequently. I'll take someone any day who is paranoid about pitfalls over someone who constantly overlooks problems like concurrency or scale.
6. "Tell me the name of this thing so that I can Google it." Every one of us had to learn the name of something at some point. Don't be a gatekeeper to knowledge. Be a facilitator.

Don't get me wrong, I have no illusions of actually changing the minds of those who control what questions get closed around here. I'm fully aware of your objections, so you needn't leave them in the comments. This answer was not written for you.

If your question was closed and linked here, know that at least one high-rep user has your back and is trying to change things.