What have I missed in asking a subjective question?

Question

Before posting my question I searched to see if I could find some similar question (which I did not). I read the faq, and I did read the Good Subjective, Bad Subjective blog. I phrased the question in a way so that I cannot see how I stronger could try to stimulate "Back It Up!" answers.

Was it overly broad? I do not think so, I both provided a project context which limits it as well as I specifically limited it to not include thinks like working conditions etc. Maybe it was a bit short, but do I have to write a novel to ask subjective questions?

Despite my effort to keep the question on topic it was closed. What have I missed? What could I have done differently to not have it closed?

Answer 1

I don't think the question is really answerable, you are essentially asking for "war stories", that's more appropriate for a discussion forum, imho. What is the problem you are trying to solve and how are you going to pick a solution from all our experiences? Is there an answer to the question, or just an endless lists of what everyone's experience was?

There is a follow up to the Good Subjective, Bad Subjective blog post, Real Questions Have Answers, that I think is a lot more clear than the Good Subjective, Bad Subjective and ends with:

I realize this is a lot of rules, a lot of guidelines, a lot of thinking. But it’s simpler than it looks. As Aarobot said in his post: real questions have answers, not items or ideas or opinions.

You are asking for items, the answers your question would generate would be equal - how can you say one's experiences are better or worse than an other's? That is discouraged in the FAQ:

What kind of questions should I not ask here?

To prevent your question from being flagged and possibly removed, avoid asking subjective questions where …

• every answer is equally valid: “What’s your favorite ______?”

Answer 2

Are you particularly concerned with a specific aspect of approaching a new code base? If, yes, why? What's troubling you and how can we help? In other words, what is the problem you are trying to solve?

Assembling a list of every challenge every one ever had, when approaching a new code base, is not constructive, in the sense that it has minimal (if any) chance of building up to a useful Q&A thread. Some of the problems with questions that fall into the "equal answers" category are:

• When does it end?

  Every user who ever had to face a new code base can add their answer, why wouldn't they? But how is that helpful? It would be extremely interesting to read (for a while) but after a point it would be just a big pile of repetitive answers.

• How do we vote?

  We are not looking for a single answer to every question, but we are looking for a clear set of parameters to decide if an answer is useful or not (not interesting, useful). We need those parameters so we can vote, sensibly, and help the most useful answer(s) float at the top.

  Certainly you can pick the best answer (for you) by marking it as accepted, but that doesn't really mean much, the community has final say in choosing the best answer. For me to vote, I need to know if the answer is useful, i.e. if I can refer back to it when I face a similar problem or not. If I don't know that, I don't know how to vote.

• What are you really looking for?

  Several times I've answered such questions, I quickly found out that the asker only needed a small part of my answer. They might have not realized it themselves initially, but not having clear parameters in the question, a specific problem to solve, can easily lead to such situations, and for me, the answerer, it's particularly nasty. Simply put I've wasted my time writing a long but mostly unnecessary answer.

If you are facing a specific problem, we would love to help! But as it is, your question, albeit being very interesting, it's not suitable for the Q&A format and philosophy of Programmers.