Asking the Right Questions

We've asked a lot of questions of our own in recent blogs and and we've received great feedback for which we thank you. Last week's "Japanese Imports and a New Role for COMMON?" iDevelop blog entry garnered a number of comments, mostly relating to the potential role of COMMON in such a program. This issue has been widely debated in other blogs, Internet lists and in editorials. However, since so far there's no sign of any action from North American BPs/ISVs, and no reaction from COMMON, we thought we'd let the dust settle a little and move on to a different kind of question this week.

Have you ever thought about how many different kinds of questions there are, and more specifically how the way a question is phrased can impact one's ability to respond?

For example there's the loaded question: "Just when did you stop beating your wife?"

There's the rhetorical question: "Is the pope Catholic?"

Then there's the kind of question that all too often gets asked in technical forums: "Why doesn't this code work?" This question is often accompanied with: "I'm sure this was easy in RPG400."

The second part should sound a warning gong to the questioner. You can pretty much take it as gospel that if it was "easy" in RPG400 then it is almost certainly trivial in RPG IV. In the early days of RPG IV, if the "How do you do x in RPG IV" question were posed we would often suggest that the questioner code it in RPG400 and then run it through the the source convertor to see how to code it in RPG IV. However, RPG IV has advanced so far from those early days that such an approach will almost invariably result in an inefficient (or at least less than optimum) solution. After all, RPG IV has now been around for more than 12 years.

So, those with limited RPG IV knowledge need to ask better questions these days if they want an optimal answer. And those of us who do know the language well need to be a little more careful in how we respond. And sometimes we shouldn't take the question too literally.

An example might help to clarify. The questioner asked why the approach he was using to overlay a character field with an array was being rejected by the compiler in RPG IV. The technique worked just fine in RPG400. He showed his attempted "solution", and it wasn't hard to see what was wrong with the code. It also appeared that he wanted to use the array to inspect individual characters and replace some with blanks. A number of people rushed to help, showing several different ways in which the overlay could be achieved. These solutions in turn prompted other suggestions. Most answered the question, but it was some time later before others noticed the apparent intent of the code and suggested that perhaps there were better alternatives.

In this case the best solution for the problem was not to use an array overlay, but to use the XLATE op-code or %XLATE BIF. Interestingly XLATE was available in RPG400 but our old techniques become so entrenched that the questioner had apparently missed its arrival back in the V2 days.

The net result was probably confusion on the part of the questioner, and a lot of wasted time on the part of those who tried to assist. The problem arose because the questioner had not asked the right question. Had he stated _what_ he was trying to achieve, rather than propose a solution to a partly stated problem, he would likely have received a quick and accurate answer and learned a little more about RPG IV in the process.

Don't get us wrong, if you have attempted a solution you _should_ include the relevant pieces of code. But you should always start out by stating the problem you're trying to solve.

This is just the most recent example. We've seen Internet threads go on for days (with a resulting loss of productivity on the part of all participants) before the real purpose of the exercise becomes apparent. Since information out on the WWW tends to last forever, this also has the added effect of making it harder for others to benefit from the resulting solutions as the threads become so convoluted and go off in so many directions.

So the next time you need help with a problem--whether it be from a fellow team member or on the Internet--think about how you phrase the question. Rather than asking how to make this code technique work, try stating what you need to do and ask for advice. You will most likely end up with much more valuable answers and much less wasted time. And the next time you are tempted to spend time providing a "simple" answer to a question online, think about looking deeper to provide an answer to the real question.

Comments

[david]

Eric Raymond has a very good discussion of how to ask questions the smart way ...
http://catb.org/~esr/faqs/smart-questions.html

Although targeted at online forums, it's got good ideas in general.

[Jon Paris]

Thanks David - I had heard of that document but never read it before.

It is very useful - although one might wish for a "Readers Digest" version!