Do you prefer quick and dirty or sound but incomplete answers to your problems?

Question

This is a general question about helping other programmers solve their problems, which specifically applies to StackOverflow.

Sometimes when I'm asked for help with a programming problem, I find that there are really two problems: the one that the person is asking to be solved and often a larger problem that, if solved, makes the former one irrelevant. Solving the first problem might be easy, but it leaves the larger problem behind. Let me illustrate with an example. Say someone comes to you with the problem that the following loop computes the wrong value:

let price = 6.0
let quantity = 7
let cost = 0
for i = 0 to quantity do
   cost = cost + price
end do

Cost should be 42.0 but it comes out as 48.0

Now -- you could provide a solution by pointing out that the loop index should go from 1 to quantity or 0 to quantity - 1. It would be technically correct, but not solve the real problem. They should be using multiplication! In this case it is easy to provide a sound and complete answer. Sometimes it is not so easy.

Recently I came across a question on SO using a technology that I don't know very well. What the person was doing was obviously bad code from an architectural perspective, but I wasn't well enough versed in the technology to provide a sound and complete answer. Someone else had posted a complete, but quick and dirty answer (a fix the loop count answer, if you will).

I gave it a lot of thought -- and waited for someone who knew better to post a response I felt I could up vote. Eventually I down voted the unsound, in my opinion, answer and provided an alternate answer that described architecturally what should happen and gave some pointers to frameworks that would enable it. I didn't (couldn't) provide as complete an answer (code) because I don't know the technology that well. Note that my down vote was because I felt that what was suggested was a really, truly bad practice to be avoided, not because I felt my answer was better.

As an OP, which would you prefer? Is it helpful to point you to a solution that will probably require more significant changes than required to merely fix your immediate problem? How do you feel about down votes for technically correct, but unsound answers? Does your response differ if the answer is given in person -- where you have a chance for a discussion -- or on Stackoverflow -- where discussion is more limited?

Answer 1

Why not do both? This has been brought up before under various guises. Answer the question they asked - there may be a reason for the lousy implementation that they didn't bother explaining because it's irrelevant to the problem. Then editorialize: instead of using this approach with the fix I suggested, use this other approach which solves your problem more elegantly/efficiently, and does not have this issue.

Answer 2

I would want both anwers. First, i would like to read the quick and dirty one to the problem at hand, and then how it is done right (e.g using multiplication). I've seen people calling this "nit-picking", but i don't consider it as such.

Answer 3

May be it is not necessary in such situation to vote down bad example. If you disagree with quick fix answer you can vote down or offer own variant so others could decide which is better. Doing both you make people decide which variant is better in favor to more sophisticated solution which is not very good practice itself. Let people choose what they like. And allow it your self too. :)

Answer 4

quick and dirty

Answer 5

There were questions where precise answer will take pages of code. It is hard to expect from commenters to spend their time on debugging and polishing their answers as long they are representing well the idea.

I personally prefer "you can do it by foo_bar way", "Look at BAZ 1.234.5 library" style may be followed by one-two lines of code, not more.

Answer 6

All answers are helpful answers. Each one takes a different point of view and gets you thinking about your problem in a different way.

You never know what answer, or what type of answer, will be the one that gives you that epiphany.