Book building is art and science. I've built a few books over the years at patterns & practices. In this post, I'll share a behind the scenes look at what it takes to do so. I'll save the project management piece for another day, and focus on the core of book building. 

Book Examples
Before we get into the details, here's a quick look at my past books:

• Team Development with Visual Studio Team Foundation Server (Amazon, HTML, PDF)
• Performance Testing Guidance for Web Applications (Amazon, HTML, PDF)
• patterns & practices Security Engineering Explained (HTML, PDF)
• Improving .NET Application Performance and Scalability (Amazon, HTML, PDF)
• Improving Web Application Security: Threats and Countermeasures (Amazon, HTML, PDF)
• Building Secure ASP.NET Applications (Amazon, HTML, PDF)

If you're familiar with the books, particularly Improving Web Application Security and Improving .NET Application Performance and Scalability, you'll know that the books aren't like typical books. They're optimized to be executed rather than read. The expectation is you'll use them to improve your effectiveness on the job. That's why you can get the books in the bookstore, online or in Visual Studio ... in print, PDF or HTML.

Competitive Assessments
The books are targeted at real-world problems and real-world solutions.   They've been used for competitive assessments:

• Security Innovation Security Engineering Study
• Openhack 4 (EWeek Labs): Web Application Security
• @Stake Security Study: .NET 1.1 vs. WebSphere 5.0

Book Approach
At a high-level, you can think of the approach in five main workstreams:

1. Researching and analysis.
2. Designing.
3. Building,
4. Testing.
5. Releasing.

It's a "test-driven" approach, meaning we start with tests (questions and tasks) that our prescriptive guidance needs to pass. The bulk of the work is building "nuggets" that can be used standalone.  We then assemble an end-to-end guide.   Throughout the process we verify with test cases, lab repros, internal and external reviews, both with subject matter experts and every day users.

Researching and Analysis
This workstream is about getting clarity on the problem space.  It includes:

• Identify the Key Resources in the Domain.  This is about finding all the relevant blogs, sites, articles, code, slides ... etc. for a given domain or problem area.  Here's an example of our Visual Studio Team System Resource List. 
• Identify the Key People in the Domain.   This includes enumerating internal folks (product support, field, product teams, experts) as well as external folks (partners, MVPs, customers, experts, ... etc.)
• Identify the Key Categories in the Domain.  Knowing the terms in the domain, speeds up our research efforts.  For example, if we know the names of the features for a product, we can quickly explore the product docs.  If we know how the community is tagging the information, we can quickly parse the broader "Web community KB."   Reviewing key blogosphere is a fast way to figure out the folksonomy that people use.  This helps us build information models for the space.
• Identify the Key Questions, Tasks, and Scenarios.   This is a process of making tickler lists of the questions that users ask, the tasks they perform and the key scenarios.
• Identify Key Contributors.   This includes finding folks that want to participate and actually create content.  A lot of folks raise their hands, but only a few deliver.  That's the nature of the beast.
• Identify Key Reviewers.   Finding reviewers is pretty easy since lots of folks want to steer.  The trick is finding the folks that inject insights and dramatically raise the quality of the guidance.  We cherish our key reviewers.
• Identify Key Reference Examples.  This is about gathering all the working examples we know of from support, field, and customers.  I like to be able to point to working instances of the guidance in practice.  I also like to reverse engineer success (success leaves clues.)
• Build data points.  If you're into information, these would rock your world.  These are dense collections of insights that we share among the team.  Sometimes we use a Wiki, but we always use Word docs to capture and share them, since they get are very dense and we track the sources of the information.

For more information on researching, see my related posts: Analyzing a Problem Space and How To Research Efficiently.

Designing
This workstream is an iterative process of spiraling down on solutions.  It includes:

• Create a scenario frame.  This is where we frame out the guidance.  It includes organizing scenarios into key categories and sub-categories.  This is where the folksonomy and information models helps.  Here's examples of our Visual Studio Scenario Frames.
• Review the scenario frame.   This is painful but rewarding.  We review the scenario frames with customers and experts, internally and externally.  It's a spiral down process.
• Identify the priorities.   Once we have scenario frames and we've spent the time reviewing, we're at a great vantage point to separate the forest from the trees.  One technique we use to prioritize is we ask product team members to think of the top 10 issues they'd like to make go away from their inbox ;)
• Identify candidate nugget types and titles.   This is where we figure out whether something should be a "How To" set of steps or an "Explained" articles, such as an explanation of how something works or it's intended usage patterns.  We hammer on the titles so that they both represent compelling information, they set the right expectations, and they are more findable on the Web.
• Identify the objectives for each nugget.  We identify the key "tests for success" in each nugget, by listing the specific tasks, questions or objectives you'll accomplish by using that particular nugget.  For an example, see the "Objectives" section in How To Protect from Injection Attacks in ASP.NET.
• Prototype the Table of Contents (TOC.)  I do this on the whiteboard and paint the broad strokes first.  I factor the guide into two main parts: a fast path through the key strategies and concepts, and an actionable reference of nuggets (principles, patterns and practices.)  I also come up with a story I can tell in the hall.  For example, the story behind Improving Web Application Security was "how to build a hack proof app."  That set the stage and kept things on track when things got complex (as they always do.)
• Create conceptual frameworks.   This involves figuring out the most effective ways to look at and tackle the problem space.  For examples, see Performance Fast Track and Security Fast Track.

For more information, see my related posts: Guidance 2.0, Scenarios in Practice, Scenario Frames for Guidance, and Driver's Guide vs. Owner's Manual.

Building
This workstream is where we do the bulk of our solution engineering.  It includes:

• Prototype nuggets.  This is where we frame out and create skeletal examples of nuggets.  We incrementally render the final nugget by adding information and details as we learn, build, and test.
• Create problem repros.  Reproducing problems helps to both understand the problem space as well as make it easier to share the problems and get more eyes on them.  We also need to be able to test the solutions against the problems.  We typically capture problem repros in notepad.
• Create solution repros.   This is where we create the leanest, stripped down example of solving the problem.  We capture these as steps in notepad, including copy+pastable code or configuration steps as needed.  Each person on the team should be able to quickly run through the solution repro.  This helps us find the sticking spots and reduce the friction.
• Create key figures.   This is a painful process.  The goal is find the fastest way to convey the information visually.   I think my favorite all time examples are our "cartoons" for showing our security scenarios and solutions.
• Write nuggets.   This involves fleshing out the details.   I try to keep the text as tight as possible throughout the process.  It's more work to make it dense, but it pays off where we spend the time.
• Write chapters.  This is similar to writing the nuggets but from a zoom level this is where it's about showing the forest.
• Modify the TOC.  This is a continuous process.  As we learn more about the space, it gets easier to organize the chapters and nuggets into parts and a story that we can stand behind.
• Refactor nuggets and chapters.   For an example TOC, see the Landing Page for Improving Web Application Security.

Testing
This workstream is about verifying the solutions from both a technical and user experience perspective.  It includes:

• Test solutions in the lab.  Since the bulk of our books are executable, it's fairly straightforward to test the solutions to make sure they work in the lab.  Scenario and scoping is important, so this is where our scenario frames and objectives for each nugget really help.
• Test solutions in the field.  This is where we try to find customers that share the problems we've solved and put our solutions into practice.   Usually, this involves leveraging our field or product support that acts as a proxy for the customer.  We also have a few customers running alongside us that can help test in their scenarios.
• Dog Fooding.  One rule I have on our team is eating our own dog food so we have first hand experience with the usability of the guidance and can directly use it to solve problems.  See Eating One's Own Dog Food on Wikipedia.
• Review solutions.   This includes reviews from internal and external stakeholders.  We do this incrementally.  First our immediate team has to approve, next our immediate key contributors and reviewers (the ones that have more bandwidth and commitment) and then more broadly (such as on CodePlex.)  For an example of the sets of reviewers, see the Landing Page for Improving .NET Application Performance and Scalability.
• Improve solutions.  Rather than just focus on finding issues or proving that something technically works, it's about raising the bar in terms of user experience, or finding a more effective technique or solution.  We use Timeboxing to help scope. See How To Use Time Boxing for Getting Results.

For more information, see my related post: Test-Driven Guidance.

Release
This workstream is about making the guidance customer available.  It's incremental, iterative and we stabilize over time.  it includes:

• Create an online community KB.  This is where we create an online site to share the nuggets.  For an example, see our Visual Studio Team System Online Community KB on CodePlex.  By sharing the nuggets here, we can test and vet before baking into more durable form factors such as the PDF and print versions.
• Create a PDF.   We do this once we've stabilized enough that the PDF is a good example, of what the final book will be.  While details may change, the overall frame is durable and we use the PDF as a simple way to share the book before we're baked.  For an example PDF, see patterns & practices Team Development with Visual Studio Team Foundation Server.
• Create the book.   This includes creating a fit and finish PDF, as well as creating print-quality graphics, and coordinating with our MS Press team to create the final print versions of the book, as well as getting the book on the shelf.
• Port to MSDN.   We port the guidance to a MSDN so that we get better reach and because customers expect it there.  In the ideal scenario, we host the PDF and HTML, as well as have a print version.

Keep in mind that it's a stabilization process over time of various form factors and channels.  We do our agile guidance on CodePlex, then stabilize and port to MSDN and a book when we're baked.  For more information, see my related post CodePlex, GE and MSDN.

Key Concepts
I walked through the process first so that you have a good idea of the end-to-end approach.  Here I'll highlight some of the key concepts that underlie my approach:

• Solution Engineering.  This captures the heart of what we do.  Rather than "writing a book", we're really engineering solutions for problems.  That's why the team includes architects, testers, developers ... etc.
• Question-Driven.  I'm a fan of using questions to prioritize, drive the scope, and figure out when we're done.  I know we're done when we've addressed enough of the right questions.
• Principles, Patterns, and Practices.  The bulk of the book is a collection of principle-based recommendations.  Although we don't always formally write up patterns or name the patterns, each book contains pattern-based solutions.
• Life Cycle Approach.  I find using a life cycle makes the solution stronger.  If I just give you technical guidance, that only helps you so far.  If I give you a system for results, it changes the game.
• Test-Driven.    I'm a fan of using explicit test cases for content.  See Test-Driven Guidance.
• Conceptual Frameworks.   This is the backbone of the guides.  This is where innovation happens the most.  These are mental models, lenses and perspectives, and systems for results.  For an example, see Fast Track - A Guide for Getting Started and Applying the Guidance.
• Scenario-Based Approach.  You can't do a design review in a vacuum.  We use scenarios to evaluate against.
• Scenario Frames.  Scenario Frames are organized sets of usage scenarios.   We use these to frame out the problem space.   See Scenario Frames for Guidance. 
• Executable Content.   Use the content to execute your tasks.
• Action vs. Reference.   One key to building executable content is factoring reference information from action.
• Guidance Types.  Another key to building executable content, is using specific guidance types.  For "reference" information, we use "Explained" nuggets.  For "action" information, we use "How Tos", "Checklists" ... etc.   Our guidance nugget types include: App Scenarios, At a Glance, Checklist Items, Code Examples, Explained, Guidelines, How Tos, Inspection Questions, Patterns, Practices, Principles, Roadmaps, Techniques, and Test Cases.  You can browse these collections using patterns & practices Guidance Explorer.
• Context-Precision.    This is a term I coined to get more specific about the scenario.  This improves both the modularity of our nuggets as well as the usability.  Rather than a single nugget spread over many contexts, we factor and use precision.  This avoid a spaghetti problem and helps reusability and maintainability.  See Context-Precision.
• Holistic Over Piecemeal.   The guides are meant to get you up and running.  The example I use is teaching you to drive.  I show you how to forward, reverse, steer, brake, shift to get you going and then drill into shifting or braking as needed, rather than show you how to go forward today, then how to reverse another day, and some day how to steer.  This means compressing and distilling knowledge that's been spread out over time and space.  
• User Effectiveness Over User Sat.  To do my job well, I focus on customer effectiveness over customer satisfaction.  Ideally, it's both, but there's a lot of FUD in our industry and satisfaction is very subjective.  I find it more reliable to focus on measuring and testing customer effectiveness.
• Criteria for Effectiveness.  Part of what makes this successful is having criteria for the guidance which includes: Compliance with proven practice, complexity, quality, user competence and time to implement.
• Incremental Adoption.  Each guide is designed to be incrementally adopted.  While the sum is better than the parts, I can't ignore the reality that incremental adoption is more likely than monolithic adoption.  That's why the guides can be read end-to-end, or just grab the parts you need.
• What To Do, Why, and How.  While this pattern directly applies to writing prescriptive guidelines, it really exemplifies the overall guide.  Rather than lose you in endless enumerations of options, you should be able to quickly figure out what to do, why, and how throughout the guide.
• Entry Points.    How does a user find the specific guidance they're looking for?  I tend to focus on "question-based" entry points and "task-based" entry points.  You're either asking a question or trying to figure out how to do something.  For an example of question-based entry points, see VSTS Source Control Questions and Answers.  For an example of task-based entry points, see ASP.NET 2.0 Security Practices at a Glance.
• Team Guidance.   Few problems can withstand sustained thinking.  No problem can withstand sustained collective thinking.  To get an idea of the team-based approach, see the list of contributors and reviewers at the bottom of the Landing Page for Improving .NET Application Performance and Scalability.
• Customer-Connected Engineering.   Simply put, this means involving customers throughout the process.  How would we know we have the right problems or the right solutions without involving the people it's for?

Feedback
How do you build books? If you have thoughts, questions or feedback on my book building approach, feel free to share them here or drop me a mail.  While this approach has been proven effective over time, there's always room for improvement.  I'd like to hear what works for you.  If you're a fellow book builder, please share your approach.

My Related Posts

• CodePlex, GE, and MSDN
• Guidance 2.0
• From Guide to Guidance Modules
• Test-Driven Guidance
• Writing Prescriptive Guidelines

One of the questions I get is how we build and publish our guides and what's the relationship of CodePlex, GE and MSDN.  At a high-level, we build reusable guidance nuggets for customer questions and tasks.  We then build a larger guide to bring the nuggets together into a story. Together, this gives us both a knowledge base of nuggets and a series of guides.  We can incrementally deliver value, refactor as appropriate, and respond to changing needs.

Bird's-Eye View of Agile Guidance Engineering
You can think of our approach as progressive rendering of solutions (incrementally sharing and stabilizing.)

From CodePlex to MSDN
As we build guidance modules, we publish them to GE and CodePlex.  GE lets you, the user, build more relevant views or tailor the nuggets to your own needs.  CodePlex gives us a place to experiment with views and get direct user feedback, while we vet the guidance. 

Once we're stable, we do a focused, batch effort to port to MSDN.  MSDN gives us a bunch more channels and hooks including integration in Visual Studio / Visual Studio Team System.

There's much more to the story, so if there's interest, I'll share a behind the scenes look at how we build books.

My Related Posts

• Test-Driven Guidance
• From Guides to Guidance Modules
• How To Write Prescriptive Guidance Modules

What's one path the SDL (Security Development Life Cycle) can take to amplify impact?  From my perspective, I think the key is specialization for app types and verticals.  I base this on lessons learned from  shaping prescriptive guidance over the years, the market trend for specialization, and what I learned doing competitive assessments. I also know the enormous difference that getting specific can make (for example, our original patterns & practices threat modeling was one-size fits all -- now we shape it based on app type.  This lets us integrate more precise "building codes," patterns, and recommendations.)

Conceptual Framework / Mental Model
Here's a strawman I put together of a conceptual model to paint the possibilities.

App Types
Imagine app-type specific prescriptive guidance, services, tooling, process  ...

• SDL for Web Applications
• SDL for Mobile
• SDL for Web Services
• SDL for SDL for Smart Clients
  … etc.

Verticals
Imagine SDL for verticals ...

• SDL for Manufacturing
• SDL for Financial
• SDL for Retail
  … etc.

Key Concepts

• SDL for App Types means specific “building codes” (ASP.NET security guidelines, ADO.NET security guidelines … etc.)
• SDL for Verticals means industry specific guidance for security requirements (HIPPA, … etc.)
• SDL for Vertical and App Types can be turned into “Factories”
• SDL for Verticals and App Types can be turned into “MSF Templates”
• SDL for Verticals and App Types means “right-sized” services.

Key Assets
My take on what the various parties bring to the table ...

• patterns & practices.  Expert techniques, guidelines, checklists, patterns, “building codes”, how tos, Factories, Guidance Explorer, Vertical Solutions, Customer Verification, Influencers, MSDN Channel, VSTS channels/hooks.
• ACE.  Execution / Services Delivery excellence, libraries of threats, attacks, vulnerabilities, countermeasures, Enterprise Threat Modeling Tool.
• Visual Studio Team System.  Factories, MSF Templates, Code Analysis Rule Sets, Code Analysis Tools, integration of people/process/tools.
• SDL Team(s).  Process Model, Product Recommendations, Security Engineering excellence

While it requires a bit of coordination and focus in key areas, I think it's both technically feasible and would deliver a ton of customer value.  The sum is better than the parts.  Thoughts?

Threat Modeling is a way to identify potential security issues to help you shape your application's security design.  If you need to create a threat model, and you aren't sure how, here's some links to get you started.  (Note that our patterns & practices threat modeling approach is adaptable for agile scenarios.  In fact, our dominant set of customers we tested our approach with were using agile methodologies.  I'll cover doing agile security another day. )

Getting Started

• At a Glance: Threat Modeling Web Applications
• How To: Create a Threat Model for a Web Application at Design Time
• Walkthrough: Creating a Threat Model for a Web Application
• Template: Web Application Threat Model
• Template Sample: Web Application Threat Model
• Cheat Sheet: Web Application Security Frame

Key Links

• Threat Modeling Web Applications (Landing Page)
• Alex walks through our Threat Modeling approach
• Security Engineering Explained

My Related Posts

• How Do I Explain Threat Modeling to Customers
• What Makes a Good Threat Model
• Threat Modeling Terms and How To Use Them
• High ROI Security Activities
• Security Approaches That Don't Work
• Security Engineering Explained
• Video: Proven Practices for Security Engineering

This is an oldie but a goodie.  Alex (from our original team) walks through our patterns & practices Security Engineering Approach.   I knew the video exists, but I had a hard time finding it again so I'm posting the link here.

Video

• MSDN Architecture Webcast: Proven Practices for Security Engineering (Level 300) 

Key Changes
A few things have changed since our original video:

• We changed from reviews to inspections (Security Design Inspection, Security Code Inspection, and Security Deployment Inspection)  In our approach, we *inspect* for criteria.
• MSDN moved our Security Engineering landing page.
• We released Guidance Explorer which supports doing Security Inspections.  It includes collections of security inspection questions, security principles, patterns and practices.  See How To Use Guidance Explorer to Do a Security Code Inspection.

My Related Posts

• patterns & practices Security Engineering Explained
• Security Inspections
• Security Frame
• Security Innovation Security Engineering Study
• Videos: Security, Performance, and Visual Studio Team System

If you have to compete for resources or budget or sell an idea, one of the keys is a business case.  One way to think of a business case is "how big is the pie" and "what's your slice."  You use the business case either to argue for your project or in argument against other projects competing for the same resources and budget.

The Three Keys of a Business Case
Because the business case is such a critical piece of the project puzzle, I asked one of my mentors for their take on an effective business case.   Here's the keys:

1. Problem has to be apparent .  It's apprehensible.  As a stakeholder, I can attach to it.   It's real.  I relate to the examples.  I can see it, smell it, and can relate to instances of it.
2. Compelling benefit.  It has to be meaningful to the stakeholders (spell out what's in it for them.)
3. Clear path to return.  How do I realize the path?  When do I start getting paid? Cut my staff by 1/2 when?  What actions happen that are specific to the stakeholders ?

The Fourth Key
My mentor was on a roll and added an additional key: 

4.  Risk / reward "options."  The key is to be able to chunk down the value or the risk into an acceptable size (right-size the risk.)  For example "I like your idea, but it's too big a chunk to bite off."

My Related Posts

• User Experience, Tech Feasibility, and Business Value
• Time-Boxes, Rhythm, and Incremental Value
• Vision Scope Template
  

How do you design an org?  While there's lots of approaches, one of my mentors shared the 5 Ps approach with me.  To think about the org, you need to enumerate the 5 Ps to define the organization, the type of talent you need, overall organizational competencies, culture, etc.  If you don't know what you're trying to do, you don't know who to hire.

The Five P's
The 5 P's are:

1. Purpose: What problem are you trying to solve and for who? This has to be more than a mission statement.
2. Principles: This should touch on both the culture you want to develop as well as your guiding light in how you think about the problem you're solving and tradeoffs you will need to make. This should effectively establish your decision making framework on what tradeoffs you are and are not willing to make.
3. Priorities: Enumerate all the things that are important to you, now stack rank them to focus the organization.
4. People: Enumerate the types of people, competencies, experiences, and roles you need to support your Purpose. Quantify how many of each type you need.
5. Process: This defines the rhythm of your business. Do you do monthly, semi-monthly, or quarterly progress reviews? With what frequency does your "leadership team" meet to discuss issues? How frequently is your management going to check in on the organization. Note you should stay away from detailed processes like scrum vs. waterfall and other day-to-day implementation details.

It's one thing to get results.  It's another to articulate them.   Having a way to frame results can help both for personal learning, as well as review time when you have to reflect on accomplishments.

Commitment, Results, How, Evidence, Analysis

I've found framing results by listing the commitment, the results, the how, the evidence and the analysis to be pretty effective over the years.  I'm a fan of concrete examples, so here's an example:

One of the key experiences you get with Guidance Explorer (GE) is support for manual security inspections.   We call them inspections versus reviews because we inspect against specific criteria.   We supply you with a starter set of inspection questions, but you can tailor them or add your own. 

Security Code Inspection
We use three distinct types of inspections:  design, code and deployment.  For this example, we'll use Guidance Explorer to do a security code inspection of an ASP.NET application. 

Summary of Steps

• Step 1. Create a new View.
• Step 2. Add inspection questions to your view.
• Step 3. Save your View to Word.

Step 1. Create a new View. 
In this step, you add a new view to My Views.  To do so, in GE, right-click, My Views, and add a new View.  You can name your View whatever you like, but for this example, I'll name mine "Security Code Inspection."

Step 2. Add inspection questions to your view.
In this step, you add relevant security inspection questions.    To do so, in GE, click the patterns & practices Library, next click Security, next click Security Engineering, next click Code Inspections.  Expand the ASP.NET 2.0 set of security inspection questions.

For this example, drag and drop the questions from the following categories: Input and Data Validation, Forms Authentication, and SQL Injection.  This will give you a nice focused set of questions to drive your inspection.

Step 3. Save your View to Word.
In this step, you save your View as a Word doc.  To do so, right-click your view (e.g. "Security Code Inspection") and click Save Vew as ....  Name your doc (e.g. "My Security Code Inspection.doc") and click Save.

You just built your own security code inspection set!

Extending and Exploring
There's a lot of exploring you can do and ways you can extend:

• Design and Deployment Inspection: For example, you can try building a security design inspection set or a security deployment inspection set. 
• Code Examples.  You can add code examples and link them to your inspection questions.
• Agile Security Engineering.  If you're doing Agile development, you can scope your security inspection to a finite set of categories for a specific set of stories within the current iteration. 
• Patterns. If you're a fan of patterns you can add pattern examples to your design inspection.  At the end of the day, do what makes sense for you and your team to more effectively build software and meet your security objectives.

Share Your Stories
I'm sure you're bound to have stories.   If you haven't done security code inspections before, you're in for a treat.  Security Code Inspections are a proven practice.   While the criteria and context may vary, the technique pretty much remains the same.  Share your stories either in this post or send email to getool@microsoft.com.

My Related Posts

• New Release: Guidance Explorer is Now on MSDN

This is a significant release for Guidance Explorer (GE).  Our online "guidance store" is now hosted on MSDN.  To take advantage of this, you need to download the new version of Guidance Explorer (release 20071206)

What Is the Guidance Store
Our guidance store is a catalog of reusable guidance nuggets for helping you build applications.  The catalog is organized by the following:

• Types (e.g. principles, patterns, practices, guidelines, checklists, how tos, Q&A, app scenarios, code examples ... etc.)
• Topics (e.g. security, performance., project management, reporting, build, ... etc.)
• Technologies (e.g. .NET Framework, ADO.NET, ASP.NET, XML, SQL Server, Visual Studio Team System, Web Services ... etc.)
• Techniques (e.g. security inspection, performance inspection, threat modeling, performance testing ... etc.)

At a high-level, you can think of the catalog as a collection of application scenarios, "building codes" and engineering practices.

What is Guidance Explorer
Guidance Explorer is a smart client application that talks to the Guidance Store over a Web service.  You can use GE to create, organize and share your favorite guidance nuggets.

Key Usage Scenarios
The key usage scenarios are:

• Find relevant patterns & practices guidance.
• Build customized checklists for your development scenarios.
• Build customized guidelines for your development scenarios.
• You can build custom sets of guidance and share with your team as recommended practice.

To put it another way, you can use GE to slice and dice the patterns & practices catalog, tailor the guidance, or build your own guidance. 

What's New in the Latest Release
What you can expect in Guidance Explorer version 20071206:

• MSDN now hosts the guidance store (the guidance catalog is now hosted in MSDN labs)
• Improved catalog of guidance (it's more than 3,000 nuggets)
• Improved general usability, reliability, performance, and security
• Improved view structures in My Views and the patterns & practices Library
• Improved authoring/editing experience (tweaked the UI to feel better, improved reliability, fixed copy+paste from Word and added image support)
• Improved pushing down guidance types (if we do a new guidance type, you’ll get it now)
• Improved pushing down new views (if we change our views, you’ll get them)
• Improved deploying guidance stores (if you are a hosting your own guidance store, you can deploy it more reliably)

How's that for guidance as a service?  (Personally, I think the next step is relevant guidance feeds for guidance mash up scenarios.)

Getting Started

1. Download Guidance Explorer.
2. Unzip to a directory.
3. Run the .EXE file from the \bin file.

When you run GE the first time, let it synch for about 10 minutes.  It's downloading more than 3,000 items from our catalog.

Test Driving Guidance Explorer
Here's a few of the first things to try

1. Build your own playlist of guidance (create a new view under My Views and then drag your favorite guidance nuggets into it.)
2. Build your own guide on the fly (create a view of your favorite nuggets and save the view to a Word doc.)
3. Tailor an existing guidance nugget (double-click an item, click Edit, make your modifications then save to My Library.)
4. Write your own guidance (right-click My Library and add a new Item.)
5. Create a new focused library (right-click Libraries, click New Library, name your library then add some new items.)

Key Links

• Guidance Explorer Home
• Download Guidance Explorer release 20071206
• FAQ for Guidance Explorer release 20071206
• General FAQ

I created a recurring appointment in Outlook for Fridays.  It's a checklist of key leadership practices from The Leadership Challenge.  Each Friday, I scan this checklist and reflect on how well I've demonstrated the practices and where I need to tune for the upcoming week. 

Leadership Checklist 

Model

• Sets a personal example of what to expect?
• Makes certain that people adhere to agreed-on standards?
• Follows through on promises and commitments?
• Asks for feedback on how actions affect people's performance?
• Builds consensus around organization's values?
• Is clear about philosophy of leadership?

Inspire

• Talks about future trends influencing work?
• Describes a compelling image of the future?
• Appeals to others to share a dream of the future?
• Shows others how their interests can be realized?
• Paints "big picture" of group aspirations?
• Shows conviction about meaning of work?

Challenge

• Seeks challenging opportunities to test skills?
• Challenges people to try new approaches?
• Searches outside organization for innovative ways to improve?
• Asks "What can we learn?"
• Makes certain that goals, plans, and milestones are set?
• Experiments and takes risks?

Enable

• Develops cooperative relationships?
• Actively listens to diverse points of view?
• Treats people with dignity and respect?
• Supports decisions other people make?
• Gives people choice about how to do their work?
• Ensures that people grow in their jobs?

Encourage

• Praises people for a job well done?
• Expresses confidence in people's abilities?.
• Creatively rewards people for their contributions?
• Recognizes people for commitment to shared values?
• Finds ways to celebrate accomplishments?
•  Gives team members appreciation and support?

.

Our patterns & practices Performance Testing Guidance for Web Applications book is now available on Amazon.

• Buy the Book on Amazon
• Download the PDF
• Browse the HTML

Our patterns & practices Team Development with Visual Studio Team Foundation Server book is now available on Amazon.

• Buy the Book on Amazon
• Download the PDF
• Browse the HTML

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

You can now find our patterns & practices Performance Testing Guidance for Web Applications on MSDN in HTML.  It's the same guidance we hosted on CodePlex.  CodePlex was our channel for agile release of the guidance.  Once we baked the guidance, we ported it to MSDN.

Contents at a Glance
Here's the

• Landing Page
• Foreword By Alberto Savoia
• Foreword By Rico Mariani
• Introduction

Chapters

• Chapter 1 – Fundamentals of Web Application Performance Testing
• Chapter 2 – Types of Performance Testing
• Chapter 3 – Risks Addressed Through Performance Testing
• Chapter 4 – Web Application Performance Testing Core Activities
• Chapter 5 – Coordinating Performance Testing with an Iteration-Based Process
• Chapter 6 – Managing an Agile Performance Test Cycle
• Chapter 7 – Managing the Performance Test Cycle in a Regulated (CMMI) Environment
• Chapter 8 – Evaluating Systems to Increase Performance-Testing Effectiveness
• Chapter 9 – Determining Performance Testing Objectives
• Chapter 10 – Quantifying End-User Response Time Goals
• Chapter 11 – Consolidating Various Types of Performance Acceptance Criteria
• Chapter 12 – Modeling Application Usage
• Chapter 13 – Determining Individual User Data and Variances
• Chapter 14 – Test Execution
• Chapter 15 – Key Mathematic Principles for Performance Testers
• Chapter 16 – Performance Test Reporting Fundamentals
• Chapter 17 – Load-Testing Web Applications
• Chapter 18 – Stress-Testing Web Applications

Download
You can download the patterns & practices Performance Testing Guidance for Web Applications from CodePlex.

Guidance Explorer Scenario
If you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex.  Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit.  You can then save your view or an item to Word or HTML

Today we posted our Performance Testing Videos to CodePlex.  They're a companion set for our patterns & practices Performance Testing Guidance for Web Applications.

Video Index
Here's a list of the videos: 

• Video: What Is - The Core Activities of Performance Testing (Length: 4:32 - Size: 3.02 MB)
• Video: What Is - The Core Activities of Performance Testing in Agile Projects (Length: 3:02 - Size: 2.38 MB)
• Video: What Is - The Core Activities of Performance Testing in CMMI Projects (Length: 2:55 - Size: 2.15 MB)
• Video: What Is - The Distributions of Data for Performance Tests Results (Length: 3:32 - Size: 2.39 MB)
• Video: What Is - The Reporting Fundamentals for Performance Test Data (Length: 1:58 - Size: 1.45 MB)
• Video: What Is - The Success Criteria for Performance Test Projects (Length: 2:12 - Size: 1.49 MB)
• Video: What Is - The Mathematical and Statistical Principles for Performance Testing (Length: 2:47 - Size: 1.83 MB)
• Video: What Is - The Modeling Application Usage for Performance Testing (Length: 2:25 - Size: 1.70 MB)

Additional Resources

• patterns & practices Performance Testing Guidance (Online KB)
• patterns & practices Performance Testing Guidance for Web Applications (Guide)

You can now find our patterns & practices Team Development with Visual Studio Team Foundation Server guide on MSDN in HTML.  It's the same guidance we hosted on CodePlex.  CodePlex was our channel for agile release.  Once we baked the guidance, we ported to MSDN.  For some customers, MSDN is a trusted source, so being on MSDN is important.  Additionally, MSDN provides some additional hooks and channels.

Contents At a Glance
Here's the guide at a glance

• Landing Page
• Foreword By Jeff Beehler
• Foreword by Brian Harry
• Foreword by Rob Caron
• Introduction

Chapters

• Ch 01 – Introducing the Team Environment
• Ch 02 – Team Foundation Server Architecture
• Ch 03 – Structuring Projects and Solutions in Source Control
• Ch 04 – Structuring Projects and Solutions in Team Foundation Source Control
• Ch 05 – Defining Your Branching and Merging Strategy
• Ch 06 – Managing Source Control Dependencies in Visual Studio Team System
• Ch 07 – Team Build Explained
• Ch 08 – Setting Up Continuous Integration with Team Build
• Ch 09 – Setting Up Scheduled Builds with Team Build
• Ch 10 – Large Project Considerations
• Ch 11 – Project Management Explained
• Ch 12 – Work Items Explained
• Ch 13 – Process Templates Explained
• Ch 14 – MSF for Agile Software Development Projects
• Ch 15 – Reporting Explained
• Ch 16 – Team Foundation Server Deployment
• Ch 17 – Providing Internet Access to Team Foundation Server
• Ch 18 – What’s New in Visual Studio Team System 2008 Team Foundation Server

Guidelines

• Guidelines: Team Build
• Guidelines: Source Control
• Guidelines: Reporting
• Guidelines: Project Management

Practices at a Glance

• Practices at a Glance: Team Build
• Practices at a Glance: Source Control
• Practices at a Glance: Reporting
• Practices at a Glance: Project Management

Questions and Answers

• Questions and Answers:  Source Control

How Tos

• How To: Add a New Developer To Your Project in Visual Studio Team Foundation Server
• How To: Automatically Run Code Analysis with Team Build in Visual Studio Team Foundation Server
• How To: Create a Custom Report for Visual Studio Team Foundation Server
• How To: Create a Risk Over Time Report for Visual Studio Team Foundation Server
• How To: Create Custom Check-in Policies in Visual Studio Team Foundation Server
• How To: Create Your Source Tree in Visual Studio Team Foundation Server
• How To: Customize a Process Template in Visual Studio Team Foundation Server
• How To: Customize a Report in Visual Studio Team Foundation Server
• How To: Manage Projects in Visual Studio Team Foundation Server
• How To: Migrate Source code to Team Foundation Server from Visual Source Safe
• How To: Perform a Baseless Merge in Visual Studio Team Foundation Server
• How To: Set Up a Continuous Integration Build in Visual Studio Team Foundation Server
• How To: Set Up a Scheduled Build in Visual Studio Team Foundation Server
• How To: Structure ASP.NET Applications in Visual Studio Team Foundation Server
• How To: Structure Windows Applications in Visual Studio Team Foundation Server
• How To: Structure Your Source Control Folders in Visual Studio Team Foundation Server

Download
You can download the Team Development with Visual Studio Team Foundation Server Guide from CodePlex.

Guidance Explorer Scenario
If you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex.  Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit.  You can then save your view or an item to Word or HTML. 

I happened to glance at the MSFT stock.  I took a snapshot because I thought it was make believe.  Either way, it made me smile.