We posted our ASP.NET 2.0 security videos, performance testing videos, and Visual Studio Team System videos to the MSDN library.

Video Index

• Video Index

ASP.NET 2.0 Security Videos
Keith Brown explains the mechanics behind some common input and data validation security issues and how to address them.

• Explained – Canonicalization
• Explained – Cookies
• Explained – Cross-Site Scripting
• Explained – Regular Expressions
• Explained – SQL Injection
• Explained – Validation Controls

Performance Testing Videos
Scott Barber explains the big picture for how to approach performance testing as well as how to do workload modeling and performance reporting.

• Explained – The Core Activities of Performance Testing
• Explained – The Core Activities of Performance Testing in Agile Project
• Explained – The Core Activities of Performance Testing in CMMI Projects
• Explained – The Modeling Application Usage for Performance Testing
• Explained – The Success Criteria for Performance Test Projects
• Explained – The Distribution of Data for Performance Tests Results
• Explained – The Reporting Fundamentals for Performance Test Data
• Explained – The Summary Statistics for Performance Testing

Visual Studio Team System Videos
Our team takes you through key source control concepts in Team Foundation Server.

• Explained – What's New in TFS Source Control
• Explained – Branching
• Explained – Workspace
• Explained – Shelving
• How To – Migrate from VSS to TFS Source Control
• How To – Setup Your Source Tree in TFS
• How To – Structure Your ASP.NET Projects for TFS

I hope we produce more videos in the coming months.  I particularly like factoring "explained" videos from the "how to" videos and keeping the videos short and focused.  I think we have more work to do here, but I think we've learned key lessons each time we've done a batch of videos.

It was a nice surprise to see that yesterday our patterns & practices Visual Studio Team Foundation Server Guide was among the top downloads on CodePlex.

The HMTL version of the guide is available on MSDN at http://msdn2.microsoft.com/en-us/library/bb668991.aspx.

 My Related Posts

• Guidance Explorer: A Top Download on CodePlex
• Now on MSDN: patterns & practices Team Development with Visual Studio Team Foundation Server Guide

I found an interesting article about contextual decision making.  "A Leader's Framework for Decision Making," an article in Harvard Business Review, is about tailoring your decision making approach based on the context.  You can use the Cynefin Framework to figure out which context you're operating in, so you can choose the most effective response.  The key is whether to categorize, analyze, probe or act.

Context's Characteristics
The Cynefin Framework includes five context types:

• Simple - Repeating patterns and consistent events; Clear cause-and-effect relationships evident to everyone; right answer exists; Known knowns
• Complicated - Expert diagnosis required; Cause-and-effect relationship discoverable but not immediately apparent to everyone; more than one right answer possible; Known unknowns
• Complex  - Flux and unpredictability; No right answers; emergent instructive patterns; Unknown unknowns; Many competing ideas; A need for creative and innovative approaches
• Chaotic - High turbulence; No clear cause-and-effect relationships, so no point in looking for right answers; Unknowables; Many decisions to make and no time to think; High tensions
• Disorder - This context is particularly difficult to recognize because of multiple, competing perspectives.  The recommendation is to break it down into its constituent parts and assign it to one of the other four realms.

Fact-based Management
Simple and complicated are part of the ordered world.  How to respond as a leader in simple and complicated scenarios:

• Simple - (The Domain of Best Practices) - Sense, categorize, respond; Ensure proper processes are in place; Delegate; Use best practices; Communicate in clear, direct ways; Understand that extensive interactive communication may not be necessary.
• Complicated - (The Domain of Experts)  - Sense, analyze, respond; Create panels of experts; Listen to conflicting advice.

Pattern-based Leadership
Complex and chaotic are part of the unordered world.  How to respond as a leader in complex and chaotic scenarios:

• Complex - (The Domain of Emergence) - Probe, sense, respond;  Create environments and experiments that allow patterns to emerge.  Increase levels of interaction and communication.  Use methods that can help generate ideas; Open up discussion: set barriers; stimulate attractors; encourage dissent and diversity; and manage starting conditions and monitor for emergence.
• Chaotic - (The Domain of Rapid Response) - Act, sense, respond;  Look for what works instead of seeking right answers; Take immediate action to reestablish order (command and control); Provide clear, direct communication.

I'm always on the prowl for sources of profound insight.  At my leadership workshop last week, I noticed the instructor had a wealth of practical insights and distinctions that aren't common knowledge.  I asked him his favorite sources of information and he listed two:

• Harvard Business Review
• The Economist

I was surprised because I had never read either before (the titles weren't appealing to me.)  I picked them up this week and it looks like they're packed with lessons learned and news I can use.  I think of The Economist as sharing business and organizational practices.  I think of Harvard Business Review as personal development applied to the workplace.  Here's a sample of some of the titles from this month's Harvard Business Review:

• "A Leader's Framework for Decision Making"
• "Solve the Succession Crisis by Growing Inside-Outside Leaders"
• "Eight Ways to Build Collaborative Teams"
• "Mapping Your competitive Position"
• "Cognitive Fitness"
• "Simple Rules for Making Alliances Work"
• "Are Your Engineers Talking to One Another When They Should?"

I'm a fan of patterns.  I think of patterns simply as problem and solution pairs.  I wandered by The Hogg Blog and noticed Jason's post on The Great Debate: Patterns vs Tooling.  Since patterns and tooling both have their place, I think there's less of a debate and more of a gap between state of the art and state of the practice.

Why Patterns
I think patterns are an efficient way to share insights.  Consolidating 100's of words down into a few is pretty powerful.  A pattern language is a great way to map out the terrain of a domain.  I think of the pattern language as a constellation of meaningful nuggets.  I think the most insighful nuggets are the ones that help you with the toughest forks in the road.

Patterns in Practice
While working on our security and performance guidance, our team was able to rapidly solve and share end-to-end solutions for incredibly complex application scenarios.  As we worked through customer scenarios, we would pattern match against our deployment patterns and application infrastructure patterns.  To put this in perspective, I remember a customer that had been prototyping a solution for six months, that we solved in ~3 hours because we had a collection of patterns to draw from.  We got to a vantage point where we could solve some of the toughest architetural issues for customers in a few minutes.  Looking back, I wish we had a more agile way for sharing our learnings with more customers, and I think patterns and pattern languages could have been part of the answer.

Key Usage Scenarios
There's lots of uses for patterns, but here's some examples:

• Building vocabulary.  A lot of light bulbs went off for me when Ward pointed out that patterns help build a shared vocabulary.  It's a way to talk about our craft and to hand knowledge down from one generation to the next.
• Sharing solutions.  This is what patterns do best.
• Encapsulating principles.   It's one thing to talk about a bunch of underlying principles.  It's another to have a nicely named pattern.

Key Issues with Patterns
Here's some of the issues I've run into with some patterns and repositories over the years:

• Problems solved.  I don't tend to see enough patterns around the more interesting, engineering problems where patterns are worth the effort.  I think quality attributes are great candidates for patterns (security patterns, performance patterns, reliability patterns, flexibility patterns ... etc.)
• Locked in print or teasers to more.  A lot of the most insightful patterns are locked in print.  It makes it tough to share, particularly when we don't all have the same bookshelf.
• Bad organization.  I've seen only a handful of pattern libraries that impress me.  I'm not saying they don't exist, but that I haven't seen a lot I like.
• Relevancy.  I think one of the biggest issues is just finding relevant patterns for your problem at hand.  No matter how well a library of patterns is organized, it still helps to have a shepherd.  Web 2.0 can help here.
• Bad templates.  Sometimes the structure of information is as important as the information.
• Bloat.  Blah, blah, blah.  I'm not a fan of verbosity when I need to get my job done.  I've seen some patterns that were more complicated than the solution they were describing. 
• Vocabulary.  While patterns can help build a shared vocabulary, it can be tough in the beginning, like learning yet another vocabulary.  Convergence takes time.
• Silos and pockets of insight.  I don't think patterns are as prevalent as they could or should be.  I find a lot of the best nuggets are spread a great deal over time and space.
• From concept to code can be a big jump.  Sometimes you can't get there from here, or it'a a painful process.  I think this is very much a tooling opportunity.
• Silly or make-believe patterns.  I've come across a lot of patterns that seem to be patterns for the sake of patterns.  Ward always told me that the best patterns tell you something you didn't expect or that surprised you.
• Lack of anti-patterns.  I actually think there's not enough anti-patterns.  While there's more than one way to solve a problem, sometimes there's a few places you really shouldn't go, and that's where anti-patterns fit in.   Some of the best security insights are documented as anti-patterns.

Key Opportunities for Patterns
I think there's more opportunity than ever for building better pattern libraries and leveraging social software scnearios and tooling opportunities.  Here's some examples:

• Guidance Explorer.   Guidance Exploer lets you easily cross-link patterns or link them to other items.  For example, imagine a pattern that links to a code example or a how to or a set of guidelines and checklists.  We've also played with the idea of showing patterns as mind maps so you can see the related patterns.  Guidance Explorer can also help solve the relevancy issue, by providing more fine-grained organization, as well as make it easy to build a collection of the ones you want.  All we have to do is fill up our pattern node with a critical mass of more useful patterns.
• Web 2.0.  I think Yahoo Design Patterns is a good example.
• Tooling support.  I'd like to see more drag+droppable patterns and pattern-based modeling going forward.

My Favorite Pattern Guides
Here's a few of the pattern guides I've found to be useful:

• Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0
• Patterns of Enterprise Application Architecture
• The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience (if you build Web apps, this is a MUST read)
• Head First Design Patterns (Head First)
• J2EE Design Patterns Applied
• Java 2 Performance and Idiom Guide
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (The Addison-Wesley Signature Series)

Yesterday, Ed helped me word a "law" that I use for important decisions and that I see show up quite a bit in a number of places.  It's the law of human relevancy.

The Law of Relevancy
No matter how relevant the information is, it's more relevant with the help of the right people.

The Human Shepherd
All this law really means is that no matter how well you organize and display information, at some point, there's a glass ceiling on how much easier you can make it for somebody to find what they need.  There's always a place for the human shepherd.

Usage / Examples

• The obvious example is the Web 2.0 movement -- where people are the shepherds of the read/write Web.  There's lots of needles in the world wide haystack and I'm glad there's people, voices, blogs there to help.
• I like the pattern on the Web where sites have a live chat to use a human to help you match their info to your needs, in real time.
• I like how Second Life provides the ability to "invoke a human" over just self-help and forums. (I proposed some models for "human help" in Visual Studio and as a general platform some time back I need to revisit)
• There's lots of implications for an Enterprise 2.0 world, but I'll save that for another day.

A Story
In an early version of Practices Checker (a tool meant to verify your solutions against patterns & practices recommendations), we tried to figure out relevant guidance based on the type of project (Web, winForm ...), what technologies (ADO.NET, ASMX ...) you were using, ... etc.  We did this automatically and generated what I considered more harm than help (it missed things that were important and created a lot of noise.)  I applied the law of relevancy and argued that we'd be better off figuring out how to leverage the user's own relevancy engine and pattern-matching ability over auto-magic guesswork.  We then created a tool to help smart people, rather than a "smart" tool that gets in the way.

You can build your own guide using Guidance Explorer.  Guidance Explorer is a front-end browser optimized for our patterns & practices guidance store.  Here's some of the usage scenarios:

• Build a guide of your favorite patterns & practices items.
• Build a custom set of guidelines for your team.
• Build a custom checklist for a security or performance inspection.
• Build a customized guide for your customer.

Summary of Steps

• Step 1.  Create a new view.
• Step 2.  Add items to your view.
• Step 3.  Save your view as a Word doc.

Step 1.  Create a new view.
To create a new view, right-click My Views and click New View.   Name your view.

Step 2.  Add items to your view.
For this example, select some items from the patterns & practices library node and drag and drop them into your view.  Note that you can edit the items.  Just double-click to bring up the item, then click Edit.  Once you are happy with your changes then you can save to your read write libraries (such as My Library.)  You can also create new items.  For example, right-click My Library and click New Item.  You can then add your new item to your View by dragging and dropping.

Step 3.  Save your view as a Word doc.
Once you are happy with items in your view, right-click the view and save it as a Word doc.  Note that you can also choose to save it as HTML.

Voila!  You now have your very own, custom guide.

My Related Posts

• New Video: How To - Personalize Team System Guidance with Guidance Explorer
• Guidance Explorer as your Personal Store