Every month or so, someone posts a question on one of the .NET forums I frequent asking if such and such will work, or if you can do so and so. The post will detail the background of the issue, including theoretical approaches, possible drawbacks, imaginary contingencies and tangential concepts.  Invariably the poster wants to know the "proper way" to code something, and yet 6 paragraphs later hasn't shown what he or she has already attempted.

Why?

Because the poster hasn't written any code yet. 

Philosophical development discussions can be fun. Reviewing fundamental design issues, or exploring the possibilities of a new technology or entering a new problem space beg for "what if" questions. It's good to have an idea where to go, a vague notion how to get there and to find out how others attempted the journey.   Those are fun questions to answer.

Another excellent time to ask "what if" questions is when facing an irrevocable upgrade or configuration change.  When a wrong step can wreak havoc it wise to ask for advice. That's what a forum is for -- to get pointed in the right direction or pushed back on course or to be told to hurry back to shore.

No, what makes a coding "what if" question a total waste of time and bandwidth is when it asks how to write a relatively small amount of code. The post itself is longer than the most convoluted possible solution. To put it programmatically...

if(Post.Length > Code_Needed_To_See_If_It_Works.Length)
    WasteOfTimeAndBandwidth();

In other words, if the poster had actually tried to code one of the carefully penned theoretical approaches, he or she would have ended up typing a lot less and would have discovered the solution without a trip to forum land. 

Some examples (and I wish I were making these up):

• Is it possible to set SomeObject.SomeProperty = SomeValue?
• Can I put this control inside this other control?
• How long will SomeObject.SomeMethod() take to run?

Programming is a wonderfully empirical undertaking. With IDEs (Integrated Development Environments such as Visual Studio) it is easy to create code and test it.  At the level of of a function or even a web page or windows form, there is no need for thought experiments or theoretical ponderings -- the code either does what it is supposed to or it doesn't.  There is no need to write about it -- just write it.  If it doesn't work, then you can post a question that is based on something real.

Unless you are doing something silly like working on a production system, the cost for trying something out is minimal.  In the worst cases, bad code throws an error or just doesn't work.  Things don't explode, no one dies.  With source code/version control (which everyone should get into the habit of using), it is trivial to roll back to a previous working version. 

So please, for your sake and Pete's, try it first.  See what happens.  You'll save some time and might be pleasantly surprised.