DevSource: In your blog, you said: The Microsoft Patterns and Practices team has just started publishing the Patterns and Practices Digest. I have done a bunch of conference presentations and have spent a lot of time talking to people about this, and am always amazed at how many serious developers still aren't aware of this stuff. What is the Patterns and Practices team doing, and why do you think it's important? More specifically, what can a developer accomplish by using patterns that she can't do otherwise?

The Patterns and Practices team is one of the most under-utilized and under-appreciated teams in Microsoft. Microsoft has made a tremendous investment of time and talented resources in something that does not, and will not, generate any revenues. I like to explain their mandate in the following manner. With each new version of Visual Studio and other MS developer tools and platforms, it becomes easier and easier to build really bad applications. For some reason, there are people who think that having a very productive development tool and environment means that you don't need to design or really think about the software systems you are developing. Of course, this is ridiculous. But what happens is that people develop applications without giving much thought to established knowledge and best practices and then blame the tools and Microsoft when the application isn't scalable, reliable, or maintainable. Microsoft can justifiably argue that it is not her fault, but that would be rather futile. Instead, Microsoft established the Patterns and Practices effort to help ensure that developers had the guidance and additional tools and information they need to build and maintain successful .NET applications.

The help this team provides is directed to both developers and IT/Operations staff and takes several forms. This is not just more MS marketing materials; this is serious real-world lessons and techniques, gleaned mainly from Microsoft Consulting Services and third-party experts developing real-world applications in the field.

• First, there is prescriptive guidance. These are documents on how to best build and later manage .NET applications. These range from managing and securing Exchange, SQL, and IIS servers, to how to properly architect distributed applications, handle exceptions, and access data.
• The second form of help is on the promotion and explanation of industry standard design patterns. These have been around (and largely ignored) for a long time, but have been proven to be very effective and useful to anyone who has taken the time to understand some of them, and to then look to see where they are relevant in their specific applications. It is not really tied to .NET technology; it is just good software engineering practice.
• The third element of the Patterns and Practices efforts, and probably the most popular, is the implementation of general-purpose application blocks. These are discrete units of functionality that implement MS best practices. But they are not merely a black box, like you would get from a third-party control vendor. First of all, there is usually a very extensive guideline document that explains the principles and tradeoffs on which the application block is based. Moreover, as I mentioned earlier, full source code is supplied for the application blocks, so that developers can see how the best practices are actually implemented in code. This also allows each developer to incorporate and/or extend each application block into his application as much or as little as appropriate.

In a nutshell, the Patterns and Practices team doesn't teach us how to use Visual Studio and the other tools — they teach us how to use them correctly. I strongly encourage anyone who is not familiar with these resources, to check it out on Microsoft.com.

DevSource: You've written one book on database programming(Database Access with Visual Basic .NET (3rd Edition)), and rumor has it that you're working on another. What's the one most-confusing thing, or the concept that's hardest to grasp, about ADO.NET (and database programming in general)? What did you expect to be confusing that wasn't?

Let me tell you what I still find to be most surprising in terms of concepts being grasped (or not). Whenever I do training and consulting or just take questions after a conference presentation, I never ceased to be amazed at two things most developers are not addressing. It is not really that they aren't aware of the issues, because usually they are. They just seem to be ignoring them. The two issues are SQL-injection threats and concurrency conflicts.

I think that any developer who comes anywhere near database application development is aware of the security threat of SQL-Injection. And yet, when I illustrate the simplest form of SQL-Injection, and what it can do to your database, they are astonished and act like they've just learned about gravity or found God. I can't really explain it; short deadlines and pushy managers just doesn't cut it.

Concurrency conflicts (what happens if two users read the same database record at the same time and the second user tries to update the record after the first one has already updated it), is a somewhat more subtle concept, and produces more subtle results as well. It is usually (hopefully) painfully obvious when a hacker has trashed your database. However, it is not always obvious that concurrency conflicts are not being handled correctly — at least not until you suddenly find that you have a lot less widgets in inventory than the computer reports, or until three people are all assigned to the same seat on an airplane. Most developers that I talk to are aware of the issue, know that it should be addressed, but actually do absolutely nothing about it.

Neither of these two issues are particularly difficult. You need to understand a few basic concepts and techniques and then "Just do it!"