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

Jeff Blankenburg has produced a great quantity of blog posts about developing for Windows Phone 7. Now he's supplementing that with an all-in-one resource page that links out to a ton of great material in addition to his own. Oh I know, you might not need to see the TV ads to learn how to develop for the thing, but I appreciate the link anyway. If you're doing phone work, or thinking about it, this list is for you.

Kate

Jennifer Marsman has built a very nice list of Windows 7 developer resources. Of course, she had me at Code Pack (the very first item she lists as a matter of fact), but she carries on, drilling into both native and managed scenarios, covering libraries, SDKs, training materials, UX guidelines, samples, blogs - even Twitter handles!

There is a LOT of material out there and it's a little bit fragmented. This is a great post to help you find your way around. Remember, if you have a Windows app, it should be a Windows 7 app!

Kate

According to Wired, C++ was born October 14th, 1985, with the publication of the first official reference guide by Bjarne Stroustrup. That's 25 years ago! I've still been "working in C++ since before Microsoft had a C++ compiler", as I like to say at the start of any C++ sessions I deliver. While that is a long time, it's not the full 25 years the language has existed - not quite, anyway.

Wired marks the anniversary with an interview with Bjarne. If you're curious about what kind of computer he uses day to day (a small Windows laptop) or what music he likes to listen to, now you can find out. Or this advice for young programmers:
I'd call that "simple but not easy", as much advice is. C++, of course, is neither simple nor easy, but it is incredibly rewarding to those who take the time to learn it and use it well, and I hope it will continue to do so for at least another 25 years.

Kate

I'm teaching OO design and UML again this term, and one of the things I emphasize to the class is the dangers of coupling. (Get your mind out of the gutter, I mean classes with dependencies on each other.) It's not about calling methods of each other necessarily; it's more about if-I-change-this-one, I'll-have-to-change-this-one-too. Changes that ripple through a system are expensive and dangerous.

When I am helping clients with interop, they are often surprised to learn how entire applications and libraries can depend on each other without ever calling each other's code. For example, App A writes a record to a database table. Service B checks the table regularly for new records (or records with a 0 in the Handled column, or whatever) and calls a web service (or whatever.) Those applications are now coupled - if a change in one necessitates a change in the format of that table (or its name, etc) then the other must be changed too. Thinking ahead and doing all you can to reduce this kind of coupling is part of the challenge of doing good application integration, even if there are no interop calls in the solution.

And then there's performance. So often left until last, it provides another consideration that you should ideally have in mind all the way along. And as Rico Mariani points out, it also couples applications and libraries you may have thought were independent:

Two subsystems that both (loosely) use 2/3 of the L2 cache are going to use 4/3 of a cache... that’s not good. There may be no lines between them in the architecture diagram but they are going to destroy each others ability to work.

Sound advice as always. Please read the post, and keep one more "don't forget" floating around as you design and architect your systems and solutions.

Kate

This is really fitting, isn't it? You have a product code named Dev10 and released as Visual Studio 2010 (with the tens not related to each other - see my history of Visual Studio and Visual C++ version numbers and release names). And today is 10/10/10 no matter what date format you prefer. So today is a great day to take a quick survey about Visual Studio 2010. Seven questions. I recommend you read them all before you start answering because they are asking about different aspects of the product and you wouldn't want to answer a question about speed with your thoughts about ui features. But it will take almost no time so go and do it.

Kate

I've gained a lot of Twitter followers in the last few days, and I'm pretty sure I know why. John Bristowe included me on a list of Canadian Developers that includes a full list of luminaries. I counted 112, and he's included blog links as well as Twitter handles. Most, but not all, are .NET developers. John follows all of them (us), which shows remarkable dedication. Why not take a look and see if there's someone there you'd like to follow too?

Kate

The Tech Ed Europe Session Catalog has been updated with my third talk. In the order they're happening, I have:

WCL322 - The Windows API Code Pack: Add Windows 7 Features to Your Application

DEV311 - Modern Programming with C++0x in Microsoft Visual C++ 2010

WCL329 - Advanced Programming Patterns for Windows 7

The first two I blogged earlier, but the third is new. Here's the abstract:

Windows 7 development in managed code can be very simple, especially for those using the Windows API Code Pack. But your integration with Windows 7 doesn't have to be limited to simple interactions with the new API. This session goes beyond the simple into aspects of Windows 7 development that have, in the past, been left for you to explore on your own. See how to create a jump list with a task that delivers a command to your application, as Messenger and Outlook do. Explore a simple and powerful recipe for connecting to Restart and Recovery, with minimal effort. Discover how Trigger Started Services can reduce your power footprint, while giving your users better responsiveness. Explore all that Libraries has to offer beyond "File Open", and learn why using a library is a better approach than having a user setting for "save directory."

It's going to be a great week!

Kate

PS: About the fourth item you might see under my name ... stay tuned!