I often hear questions about .NET development and the Windows ecosystem that deal with very specific situations. “What order do these events fire in?” “Will doing this leak memory?” “Will I see those details in a SQL trace?” “Will that be lazy-loaded?” When you’re a developer you often live and die by these kind of details, and humans are notoriously fallible – so why bother asking the question at all – why not write a simple program and find out?
I often see similar problems in the enterprise – questions that could be answered with a simple prototype, a cursory inspection of the data or the event logs, or a 5-minute discussion with the owner of an external system are left to fester and take on a life of their own. Meetings are called because we’ve got a problem calling system X’s web services. Really – what’s the problem? Well, we don’t know – we haven’t tried calling their web services. Sheesh.
Obviously it’s a judgement call on the part of the developers as to when to answer a question with a simple prototype and when to put up your hand and ask (and of course not all questions can be answered by working code). If the time it takes to ask the question properly (provide all the context, environmental details, sample data etc. to those you’re asking the question) is greater than the time it would take to answer it authoritatively yourself then DIY is a no-brainer. Similarly if you’re making an important decision that will be costly to reverse later then you’d really be foolish to take someone else’s word for it anyway, so you might as well answer the question with working code. Also, if you’re going to be blocked until you receive a response I usually ask the question, and then begin trying to answer it myself with working code (since I’m blocked anyway). Typically I find if you can’t answer the question fairly quickly with working code either you’re not clear about what you’re asking, or your question is too hypothetical (“will this work on MONO on Linux”? – if you don’t have a Linux VM lying around to test this hypothesis either there is a huge gap in your environment “test” matrix, or you’re asking a question that is purely academic).
A single data point doesn’t prove a hypothesis – all swans were believed to be white once, but all you have to do to disprove this theory is to find one black swan. If you’ve answered a question with working code, but are still doubtful go ahead and ask the question, with the evidence you’ve amassed from your code experiments included. People will see that you’re not being lazy and have taken the time to do basic investigation yourself, and hopefully people will only respond if they have something specific to add.
See also: how to ask a question http://catb.org/~esr/faqs/smart-questions.html
And the sort of people who won’t just ‘try it and find out’ are the same people who will argue about it at length rather than try it out, and then cling to a belief even in the face of evidence to the contrary.
But the real problem with the approach you advocate is that the recent projects list in visual studio is always cluttered up with muck around console apps that were only created to test a hunch.