I've been pretty active lately on StackOverflow, a question-and-answer site where people ask "what does this error message mean and I how can I make it go away?" for a variety of languages, platforms, and business purposes. There are a number of brilliant features on StackOverflow including voting on both questions and answers, and closing questions that are off topic for the site. This means less junk to wade through and a bit more confidence that any particular answer is actually going to be helpful.

One of the reasons questions get closed on StackOverflow is because they don't have an answer. There's a category of nasty questions of the form "Have you stopped [bad thing] yet?" that have no answer. If you never [bad thing]'ed in your life, then you obviously haven't stopped. Yet answering "no" implies you continue to [bad thing]. Answering "yes" implies you [bad thing]'ed for some time, but have no stopped. Either way, it's bad. So I knew the question "Should LINQ be avoided because it's slow?" was going to be closed. And sure enough, it was. But not before some really excellent answers and comments accrued to it. Like these:

• I would not avoid code because it only executes 250 million cycles a second instead of around 750 million, unless that kind of throughput is an actual business case. Also, chances are that the data comes from something that is a lot slower than this code anyway (a database, disk, ...). Go for what seems most convenient and optimize where it matters.

• Slow is irrelevant to your customers, your management and your stakeholders. Not fast enough is extremely relevant. Never measure how fast something is; that tells you nothing that you can use to base a business decision on. Measure how close to being acceptable to the customer it is. If it is acceptable then stop spending money on making it faster; it's already good enough.

• So what you're saying is that the devil you know is better than the devil you don't. Which is fine, if you like making business decisions on the basis of old sayings. I think it is generally a better idea to make business decisions based on informed opinions derived from empirical measurements.

Those last two are by Eric Lippert. Yes, that Eric Lippert. He's answered almost a thousand StackOverflow questions, and he's by no means the only product team member who's answering questions there. In addition, other answers fix a different perf bug in the asker's code (an unnecessary and expensive cast) and provide a wide range of opinions about performance decisions, architecture, choosing technologies and so on.

I love StackOverflow for fixing immediate blocking problems, but don't neglect the possibility of gaining philosophical wisdom from reading an offtopic question or two.

Kate