J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Performance Testing Videos Posted to CodePlex

    • 7 Comments

    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: 

    Additional Resources

  • J.D. Meier's Blog

    How To Use Time Boxing for Getting Results

    • 7 Comments

    Time boxing is a way to chunk up time and get results.  If you continously miss windows of opportunity or spend all of your time in one area of your life at the expense of others, time boxing can be one of your best tools.   A time box is simply a limited set of time to accomplish a result.  Think of it as how much work can you get done in a given block of time.  I use it to organize my day, drive project results, make incremental progress on problems and spend time on the right buckets in my life.

    Why Use Time Boxing
    Using time as a constraint and forcing function for results is extremely effective:

    • Avoid missing windows of opportunity.  Time's a limited resource.  If you don't treat it this way, you end up blowing project schedules, missing windows of opportunity, or doing too little, too late.
    • Spread your results across key areas.   If you spend all of your time in one area of your life at the expense of another, you can use time boxes to allocate time for important areas (such as career, mind, body, social, spiritual ... etc.)
    • Prioritize more effectively.  If you know you only have three months for that project, you can be smarter about what you bite off that you can actually finish.
    • Chunk up a problem.  Use time boxes to slice a problem down to size.  This works well if you have a daunting problem that seems too big to take on.  Timeboxes are also a more realistic way to deal with problems that spread over time.  If you can't solve a problem in a single session, then figure out the right-size time chunks to throw at the problem.  How do you eat an Elephant?  One timebox at at time ;)
    • Deliver incremental results.   You can use a time box to show progressive results.  For example, rather than all-or-nothing thinking, use time boxing to make incremental progress on a problem. 
    • Increase focus.  Giving yourself dedicated time boxes to focus on a problem help you avoid task switching, and help you stay engaged on the problem.  If you find yourself wandering too much, then chunk your timebox down even further. See
    • Increase motivation.  Make a game of it.  For example, how many sit ups can you do in 60 seconds?  Between splitting problems down to size, staying engaged on the problem and making a game of it, time boxing is a sure-fire way to build momentum and results.
    • Improve your effectiveness and efficiency.  use time boxing to tune your results.  Using a time box can help you identify areas to improve as well as refine your approach.  If you're not getting enough done within your timebox, experiment with different approaches, while you tune your effectiveness and efficiency.
    • Version your results.  It can be very liberating if you think in terms of revisiting a problem over a period of time, versus trying to get it all right up front.
    • Defeat analysis paralysis.  Analysis paralysis can be the worst enemy of results.  Use a time box to switch gears from think mode to execution.

    Summary of Steps
    Here's some prescriptive guidance for creating and using time boxes effectively:

    • Step 1.  Identify candidate areas for time boxing.
    • Step 2.  Identify your objectives.
    • Step 3.  Identify the appropriate time box. 
    • Step 4.  Execute results within your time box.
    • Step 5.  Evaluate and adapt. 

    Step 1. Identify candidate areas for time boxing.
    Identify candidates for time boxing.  This could be anything from work projects to personal projects.  Personally, I've found it the most effective to start with something small, such as starting a new exercise program.  I've also found it effective to use it to tackle my worst time bandits (any area where I lose a bunch of time, with either little ROI or at the expense of another area.)

    Step 2.  Identify your objectives.
    In this step, ask yourself what you need to accomplish with time boxing.  Examples include:

    • Meet a deadline.
    • Show incremental results.
    • Make incremental progress on a tough problem.
    • Build momentum.

    Step 3.  Identify the appropriate time box.
    In this step, figure out what a right-sized time box would be.  For example, you might have a project due in three weeks.  Within that three week time box, you might decide that if you allocate 2 hours a day, you'll produce effective results.

    The right-sized time box largely depends on what you determined in Step 1.  You might need to grow or shrink your time box depending on whether you're trying to build momentum, show results or just make progress on a problem.
     
    Step 4.  Execute results within your time box.
    Execute within your timebox and stop when you run out of time.  This can be tough at first because you might be on a roll.  This can be really tough if you are used to doing things until they are done.  What you're learning at this step is how to stay completely focused, how to treat time as a limited resource, and how to tune your results.  You're also learning how to make time boxes effective for you. 

    Start with your time box as a baseline so you can evaluate your results.  The worst mistake is to give yourself an hour for results, spend two hours, and then say what a great job you did in your one hour timebox.  Instead, do the hour, then figure out whether you need longer time boxes or if your approach needs to change.
     
    Step 5.  Evaluate and adapt.
    If it's not working, change your approach.   Using time boxing is one of the most effective ways to experiment with different techniques to find the most efficient.

    Examples of Effective Timeboxing
    Here's some examples of putting timeboxes into practice:

    • Software development.  Because our teams within patterns & practices do iterative and incremental development, we make heavy use of time boxing.  For example, within a two-week iteration, how much value can we deliver?
    • Feed reading.  Give yourself a 10 minute window and see how many useful feeds you can read.  See how you tune your feed reading skills, including choice of reader, how you prioritize, and how you choose posts to read, as well as what links to follow.  You might choose to factor your exploratory, pleasure feed reading from your personal and professional development feed reading.
    • Email.  Use time to help you outsmart your inbox.  For example, if you allocate 30 minutes for your email, but you're falling behind, instead of throwing more time at the problem, experiment with different approaches.
    • Time bandits.  Set limits on how much time you'll throw at your worst time sinks.  For example, do you spend too much time in meetings?  Do you spend too much time stuck in analysis paralysis and not enough time in execution?  Tackle your time-bandits with some hard limits.    

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    How To Research Efficiently

    • 7 Comments

    Building guidance takes a lot of research.  Over the years, I've learned how to do this faster and easier.  One of the most important things I do is setup my folders (whether file system or Groove)

    Initial Folders

    /Project X
    	/Drafts
    	/Research
    	/Reference
    
    Folder Over Time
    Over time, this ends up looking more like
    Project X
    	/Builds
    		/2007_05_26
    		/2007_05_27
    	/Drafts
    	/Reference
    		/Articles
    		/Blogs
    		/Bugs
    		/CaseStudies
    		/Docs
    		/Slides
    		/Source X
    		/Source Y
    		/Source Z
    	/Research
    		/Braindumps
    		/DataPoints
    		/QuestionsLists
    		/Topic X
    		/Topic Y
    		/Topix Z
    	/Tests
    		/Tests X
    		/Tests Y
    		/Tests Z
    	/Whiteboards
    		/Topic X
    		/Topic Y
    		/Topic Z
    


    Key Points

    • Factor reference from research.  Reference is stuff I pull in from various sources, such as slides, blogs, articles ... etc.  Research holds the notes and docs I create.  This way I avoid mixing information I create with information that I reference.  Having a place to store my reference information helps me optimize when I'm hunting and gathering resources in batch mode.  I also find that it saves me time when I have to go back and figure out where information came from.
    • Factor stages of information.  In my basic workflow, I move information from research to drafts to builds.  (where builds are guides)  Keeping them separate makes it very easy for me to know the current state of the information and it gives me a safe place to re-factor and make changes.  Research is effectively my sandbox to create documents and organize my notes as I see fit.  Drafts is where I have to make decision on what and how to share the information.  Builds is where I produce a shareable set of information.
    • Have a place for whiteboard captures.  Whiteboards is where I dump pics from whiteboarding sessions.  I'm a fan of doing braindumps at the whiteboard and quickly dumping to a place to reference.  If it's just text, I write it down.  If it's visual, I take a pic and file it.

    I use this approach whether I'm doing personal learning or building 1200+ page guides.  This approach helps me spend more time researching and less time figuring out where to put the information.

    My Related Posts

  • J.D. Meier's Blog

    patterns and practices WCF Security Application Scenarios

    • 7 Comments

    We published an updated set of our WCF Security application scenarios yesterday, as part of our patterns & practices WCF Security guidance project.   Application Scenarios are visual "blueprints" of skeletal solutions for end-to-end deployment scenarios.  Each application scenario includes a before and after look at working solutions.  While you still need to prototype and test for your scenario, this gives you potential solutions and paths at a glance, rather than starting from scratch.  It's a catalog of applications scenarios that you can look through and potentially find your match.

    Intranet
    Common Intranet patterns:

    Internet
    Common Internet patterns:

    One Size Does Not Fit All
    We know that one size doesn't fit all, so we create a collection of application scenarios that you can quickly sort through and pattern match against your scenario.  It's like a visual menu at a restaurant.  The goal is to find a good fit against your parameters versus a perfect fit.  It gives you a baseline to start from.  They effectively let you preview solutions, before embarking on your journey.

    How We Make Application Scenarios
    First, we start by gathering all the deployment scenarios we can find from customers with working solutions.  We use our field, product support, product teams, subject matter experts, and customers.  We also check with our internal line of business application solutions.  While there's a lot of variations, we look for the common denominators.  There's only so many ways to physically deploy servers, so we start there.  We group potential solutions by big buckets. 

    In order to make the solutions meaningful, we pick a focus.  For example, with WCF Security, key overarching decisions include authentication, authorization, and secure communication.  These decisions span the layers and tiers.  We also pay attention to factors that influence your decisions.  For example, your role stores and user stores are a big factor.  The tricky part is throwing out the details of customer specific solutions, while retaining the conceptual integrity that makes the solution useful.

    Next, we create prototypes and we test the end-to-end scenarios in our lab.  We do a lot of whiteboarding during this stage for candidate solutions.  This is where we spend the bulk of our time, testing paths, finding surprises, and making things work.  It's one thing to know what's supposed to work; it's another to make it work in practice. 

    From our working solution, we highlight the insights and actions within the Application Scenario so you can quickly prototype for your particular context.  We then share our candidate guidance modules on CodePlex, while we continue reviews across our review loops including field, PSS, customers, product team members, and subject matter experts. 

  • J.D. Meier's Blog

    How To Choose an Effective Blog Template or Theme

    • 7 Comments

    How do you pick the right theme for your blog?  The challenge is that it's not a linear decision and it requires satisficing to balance content,  function, and design ("look and feel").  As part of my research on effective blogging, I've been analyzing themes.  I’ve literally evaluated more than 2,000 themes and heavily modified more than 20.  I see a lot of patterns now.  I've decided to share my lessons learned, since they might save you considerable time.

    Summary of Lessons Learned
    Here's a summary of my key lessons learned:

    • Know your purpose.  You need to know what your optimizing for.  This shapes all the rest of your decisions, so if you know this, it helps.  For me, my portfolio of blogs will be online personal knowledge bases to share my learnings.  For me, that means putting a premium on organizing, browsing, searching, and sharing posts.
    • Start with a two column theme.  If you don't know where to start, start with a two-column template for your blog.  Three column templates have more moving parts and are trickier to create a clean reading experience.
    • Your content drives your theme choice.  Will you use images?  How long is your content going to be?  What types of posts will you have?  Will they vary?  Test the variations because this can have a big impact in the look and feel in your theme.  Your posts are the wood behind the arrow.  While your theme is the initial impact, your posts should be very readable and scannable.  Test the readability of your posts for different scenarios (skimming, in depth, long, short ... etc.)
    • Test how you'll use images.  Some of the themes I tested completely changed simply by adding images in the banner or in the posts.  The two main patterns are whether to use pictures in your banner or pictures in your posts.  The benefit of the picture per post approach is that your feed readers will get them.  If you use pictures in both your banner and your posts, it's tougher to help your users know where to focus.  Using a good picture at the front of your post, helps draw your reader in, particularly if they are scanning and sick of text.
    • Test key scenarios.  This includes users reading your feed, commenting, scanning your posts, reading your posts in detail, searching your blog, and browsing your blog (using your tags and categories.)
    • Choose simplicity over complexity.  You can evaluate the complexity by walking your key scenarios.  Do your eyes know where to focus when you first pull up your blog?  How tough is it to find a particular post? ... etc.
    • Trust your gut.  If something doesn't feel right, it probably isn't.  You just might not be able to put your finger on it, so ask others who might know.  Sometimes intuitively recognizing a problem is more effective than trying to logic your way through it.
    • If it's not working, change it.  As tough as it is to let things go, it's important to cut the deadwood or change things that don't work.  Experimenting opens new doors.  Some days after a long customization session it was really tough to drop the theme entirely, but I stayed focused on making my focus group happy.  That helped me keep going and continuously throw out what didn't work and carry forward lessons learned.
    • Ask your users.   While I had built up my own internal references of what good looks like, using a personal sounding board was invaluable.  I really enjoyed the surprises the most.  They forced me to challenge my thinking and test new ideas.
    • Know you can't make everybody happy.   This was really tough in the beginning.  I couldn't believe how I couldn't get any critical mass down any particular path.   What changed was I found the common denominators and patterns.  Once I chose themes that shared these patterns, then it was easier to spiral down on agreement.
    • Beware if you have to modify a template too much.  If you have to modify a template too much, something might be off.   While you can dramatically reshape a template to your liking, I think the base theme is a reflection of the designer's style and expertise.  If you find that your changing a lot of the theme, at some point you might be adjusting the theme too much and working against the theme.  In some themes, it starts to become obvious whether the designer knows SEO very well or knows how to bullet-proof their layouts or is good with overall look and feel, including typography.  That's why I paid a lot of attention to live examples and user comments to see what sorts of changes people were making, and whether they were just personal style or represented real structural or significant changes.  Spotting the patterns saved me lots of time, once I knew what I was looking for.
    • Leverage the Internet Explorer Development Toolbar.  The Internet Explorer Development Toolbar is your friend.  I couldn't have analyzed as many themes as I did without it.   The ability to quickly point at themes and reverse engineer them was invaluable.  For Firefox users, you can try FireBug, but I haven't tried it myself.  The key is to find a tool that helps you analyze the CSS HTMl, and JavasScript.

    Vital Factors in Your Blog Theme
    It's the sum of the parts that creates your overall blog theme impact.  Part of the problem that cost me so much time is I didn't know what to look for at first.  I had to go through hundreds of themes before I started to see patterns that made some themes more effective than others.  The other thing that cost me so much time is that it's a combination of factors over any one thing.  The overall look and feel is the sum of the parts.  Here's what I found to be key factors in overall look and feel:

    • 2 Column vs. 3 Column Templates.  This is a good macro-level decision because it helps divide your theme choices.  While there's exceptions, my readers told me that in general they prefer two columns over three.  They said it's a cleaner reading area, easier to know where to focus and it's simple to scroll the full page and see posts/pages on the left and the navigation/ads on the right.  If you go with a three column theme then there's a few issues.  Overall, try to find a theme where the column for posts is around two-thirds of the page and the two sidebars add up to around one-third.  In general, for three columns, my users preferred a column on the left and a column on the right with posts in the middle, versus two columns on the right.      
    • Color Patterns.  Colors and color combinations have a big impact on your blog's look and feel.  This includes your background, banner, text and links.  Your best judge is how you and your user's feel when they see the color combinations.  They may not to explain the reaction, but they'll feel something.  One of the guys on my team knows some science behind colors so he helped me better understand different reactions.  You can check Crayola's America's 50 Favorite Colors and Kuler helps you explore, create and share color themes
    • Font combinations for titles, body, and sidebar.  According to my users fonts and typography matters a lot.  This includes font size, family and colors.  This ones tough and can vary a great deal.  You need to evaluate both Initial impact and readability over time.  Again, unless you're a designer, you'll need to compare your gut reaction to different examples and test with your users.  For the main post text, What I did find was that, in general, my users preferred a white or off-white background, with dark gray font (versus black) and Verdana font.  They also prefer the post titles to clearly stand out, at least in size and style (for example Trebuchet or Ariel.)
    • Post readability.  Width is a big factor.  My users told me that when the post column is too wide, scanning is more difficult, and that when it's too narrow, they have to scroll too much.  Overall, they expect the post column to be two-thirds of the template width.  Once the width is right, then the next issue is the          
    • Effective sidebar design.   It seems like the features my user's cared about the most on the sidebars were: subscribe to RSS, search, categories, tags, recent posts and recent comments.   There was a definite preference for search and subscribe to RSS to be at the top.   
    • User experience patterns for searching/browsing.    If you have a large collection of posts this is particularly important, and pretty easy to test.  If you know your posts, you should first test how quickly you can browse and search for specific posts.  Then test the theme with your users.  They won't have the same inside information you do, so this could be very revealing how well the patterns are working.   I think the biggest factor here is using a "Read More" feature and showing just the first part of your posts when browsing categories or in search results.  The longer your posts are, the more important this becomes.
    • Effective use of images.  Choosing images for banners and posts made a dramatic difference in how my focus group responded to some themes.       
    • Effective banner design.  This can make or break the initial impact of your theme. 
    • Comment support.  Some themes host user comments better than others.  It really helps when you find a live example with many comments.  That way you can see how well it scales while maintaining readability. 
    • Effective use of whitespace.   My users pretty consistently commented on how effective whitespace really made some themes seem cleaner than others.  I think the biggest factor here was spacing between blog sections and elements.
    • Links.  My users told me they prefer links that are easy to spot versus get lost in the text, but that don't steal the show.  They also told me they prefer underlined links in posts, but don't underline in the sidebar (for example, categories, tag cloud, recent posts, ... etc.)
    • Search Engine Optimization (SEO).   I did notice that some themes seem optimized for SEO more than others.  While my user's didn't notice this, search engines will.  I think the main thing to pay attention across templates is how they use the title, description and header tags.  You can tailor how your results will show up in search results.  For categories, you should use permanent links.  This improves your URLs for the search engine using more meaningful words.  You should put your posts in only one category to avoid duplicate content from the search engine view.  You should also only show parts of each post when browsing categories, to also avoid duplicate content (as well as make it easier for a human to quickly scan all your posts in a category.)  See The Blogger's Guide to Search Engine Optimization - by Aaron & Giovanna Wall and Search Engine Optimization for Blogs - SEO.

    Key Blog Features
    Here's a quick list of the features that my focus group seemed to care about the most:

    • Title  and purpose.   The test is - do your user's quickly know which category in their RSS reader to put your blog in?
    • About page.  Your about page can quickly help clarify the promise of your blog and setting expectations.  See Skellie on How to Write the Perfect ‘About’ Page (by Numbers).
    • Categories.   Categories help your user's browse your catalog of posts in terms of key themes, as well as help clarify what your blog is really about.  It's another visual cue.
    • Search your blog.  Even if you don't have a bunch of posts, users tend to rely on search.  Once you have a bunch of posts, your search is vital.  It's like a chicken and egg scenario though.  If your search is tough to find, user's wont use it much.  If it's easy to find and convenient, they'll use it more.  Because there's so many ways to customize your search feature, the most important thing is to make it obvious that it is a search feature (and not a subscription form) and that it is scoped to your blog.
    • Tag Cloud.  Tag clouds are  nice way to provide a topical browsing experience for your blog.  There's two types -- internal and external.  Internal tags (Wordpress 2.3 has built in support) help you slice up your body of posts in a more fine-grained way.  External tags, such as Technorati tags, help showcase your posts in those social circles.  For more information, see my post, Tags vs. Categories.
    • Recent Comments and Recent Posts.  Using Recent Posts and Recent Comments is an effective way to improve your user's experience and help user's discover your other posts, as well as show signs of life.
    • Browse your posts.  Your user's will browse your posts either by categories, tag clouds, searches, or related posts.  Another entry point is Recent Comments and Recent Posts.  Another approach is to create pages that organize your posts in alternate ways.
    • Subscribe by RSS.  If a user likes your blog, it should be easy for them to subscribe.  Most blog themes I experimented with either exposed RSS in the right place, or it was easy to add.
    • Subscribe by email.   None of the templates that I experimented with exposed this by default, so it can be easy to forget about.  Some of my users pointed this out, so I tested adding subscribe by email.  
    • Comments.  One thing that my user's pointed out to me was how they like when they can scan posts and quickly see the comment information beneath the post titles, rather than at the end of the posts.  A few users pointed this out so this seems to be a common preference.  I noticed some themes did a better job than others of showcasing the comments for each post.  The key decisions are whether to show links above the post or at the end of the post, along with what font and color.  Once you're actually looking at the comments, the quick scan test will tell you how readable the comments are.  Actually add some comments yourself so you can find any surprises.

    How I Did My Research
    My research was pretty basic, but time consuming and challenging, particularly because there's a lot of variables and not much prescriptive guidance that I found actionable.   Here's what I did:

    • Searched for patterns.   I could recognize when a template looked and felt good, but I couldn't reliably figure out why.  To fix this, I filled my head with as many patterns as I could by evaluating hundreds of blogs, then evaluating thousands of templates and then by spiraling down around the vital few variables (once I figured out what they were.)
    • Set up multiple test beds.  I setup multiple test sites for testing with users.  Each test bed was a full blown blog with theme, so that I could do fast comparisons between theme A and theme B. 
    • Tested with Wordpress.  I've done testing before with Community Server and Blogger, so this time I focused on Wordpress.
    • Evaluated free templates.  I explored multiple, free template galleries to build a foundation for recognizing effective blog theme patterns.  I tried to find templates that were actively used, so I could see live implementations.
    • Evaluated templates you buy.   I ended up buying various blog theme packages so I could explore them too, to see if I could find any clear quality differentiations.
    • Modeled from effective blogs and bloggers.  I evaluated the top 100 bogs in Technorati.  I also explored lots of blog examples that my friends sent during my research.
    • Created a focus group.   I selected a subset of my users that were able to provide multiple rounds of in-depth feedback.  This helped tons and I can't thank them enough!
    • Used the Internet Explorer Development Toolbar.   The toolbar helped me quickly analyze various blog themes on live sites and then tweak my own. See Alik on using the IE Development Toolbar.

    Key Galleries I Explored
    I explored several galleries, but here's a few of the key ones:

    Key Themes I Tested
    While I tested a lot of themes, her's a few key ones that stood out:

    • Deep Blue.  Here's a live demo of Deep Blue.  I found it very clean and functional.  Some of my users liked it too for the same reasons, but I didn't get critical mass with it.
    • Easy Wordpress.   Who is Jon Ray is a good live example.  I like the theme and I like what Jon's done.  I think the theme really optimizes both browsing and reading content, and pictures work really well.  Even though it's a three column template, it's well organized.  The majority of my focus group preferred this theme.  One user thought the post column is too wide, but they read using a feed reader, so it's not a show stopper.  The majority of my focus group really liked the width and balance of the theme across the columns, and it would scale over time.
    • Grid FocusWrite To Done, Skelliewag.org, Anywired, and Six Revisions are really good live examples.  I was very partial to this theme, particularly because it has a similar look and feel to my Guidance Share Wiki (particularly after I added baby blue bullets instead of the default dark bullets.)  However, my users told me to choose otherwise. This surprised me.  I imagined I was going to be using Grid Focus.  I still think it's a great theme, but my user feedback says it's not the right one at this time for me.   
    • NeoclassicalOpen Education and Schaefer's Blog. This theme had universal appeal across my users particularly at first glance.  In fact, for a while, I thought this would be my theme of choice.  However, after more analysis, user's eventually told me the post column was too narrow, the typography was tough for extended use, and that browsability across a large body of posts might not be as effective as they would like.  The key thing I learned from Neoclassical was that images are important.
    • MistyLook with Two Sidebars. Cheap DJ Systems and Gluten Free Cooking School are live examples of the two sidebar version, and here's a live demo of MistyLook with one sidebar.   This theme is very clean and very easy to customize.  I really like the pattern of a prominent image in the banner with clean, readable posts.  The sidebars are compact too which really helps for navigation.  While most of my focus group liked the theme, they didn't like it enough to make it the final choice.   One of my focus group members really liked this particular theme, enough that it made it tough during final eliminations.
    • My April ReloadedMe, Myself, and I and Market Associates.com are good live examples.  This theme really is spectacular.  Posts are incredibly readable and scannable.  Depending on how you structure the layout, you can make it very, very clean.  There's plenty of room in the third column to fit full post titles without scrunching.  My focus group really liked this theme, but ultimately prioritized Easy Wordpress.
    • StudioPress and GreenTech.  I found these themes very clean and functional.  However, I didn't get enough critical mass to spend a lot of time investing in them.

    How I'll Use This 
    This has definitely shaped my perspective on blog themes.   It's night and day from when I first evaluated themes.  Knowing what to look for helps me test and experiment faster.  I now have a more systematic way of figuring out why some blog themes work and why some don't.  I'll be helping some colleagues with their blog themes and I'll be using what I learned as I launch new blogs.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    How To Use Guidance Explorer to do a Security Code Inspection

    • 7 Comments

    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

  • J.D. Meier's Blog

    Building Books in patterns and practices

    • 6 Comments

    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:

    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:

    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

  • J.D. Meier's Blog

    Kaizen

    • 6 Comments

    Kaizen is a Japanese term for continuous improvement.  A little Kaizen goes a long way over time.  From a personal development standoint, it's key for overcoming resistance.

  • J.D. Meier's Blog

    Rituals for Results

    • 6 Comments

    Routines help build efficiency and effectiveness.  Consistent action over time is the key to real results.  If you add continuous improvement or Kaizen to the picture, you have an unbeatable recipe for success.  The following are some of my rituals for results: 

    • Put in your hours.  I heard that Hemingway wrote for two hours a day.  The first hour he edited the day before.  The next hour, he wrote new.  My marathon runner friend says the key for her is putting in her hours.   
    • Schedule It.  If you schedule it, it happens. ("One of these days is none of these days.”)
    • Carve out time for what's important.  You don't have time, you make time.  "Work expands so as to fill the time available for its completion." - Parkinson's law.  "Things which matter most, should never be at the mercy of things which matter least." - Goethe.
    • Model the best.  Success leaves clues.  Using reference examples can help you shave off tons of wasted time.  Who can you learn from that will take your game to the next level?
    • Expand your toolset.  When you only have a hammer, everything's a nail.  Adding new tools to your toolbelt can exponentially improve your results.
    • Build a library of reference examples.   Collect working examples to draw from.
    • Build feedback loops.  I think feedback loops help us improve and keep us going.  For me, I use a sounding board of people I trust. 
    • Have a compelling "why."  A compelling "why" is what will give you the energy and get you back on your horse, when you get knocked down.
    • Have a compelling "what."  Your "what" should be a great manifestation of your "why."  Use it to guide your course.  This is your vision.
    • Check your ladder.  Is it up against the right wall?  Nothing's worse than climbing a ladder to find your destination was wrong.
    • Work backwards from the end in mind.   Working backwards from where you want to be can help make you more resourceful.  Look to working examples and reverse-engineer.
    • Stay flexible in your approach.  Be flexible in the "how."  If you have a compelling "what" and "why," you'll find the strategies.  If something's not working, change your approach.  Sanity check by asking yourself "is it effective?"  See The Better Adapted You Are, the Less Adaptable You Tend to Be
    • Think in terms of a portfolio of results.   This means both producing results in different categories as well as having some results you count on and some that are risks.  Diversify your results over having all your eggs in one basket.
    • Balance your buckets.  Balance your results across your meaningful buckets.  For me, I use a life frame (mind, body, emotion, career, financial, relationships)  Within my career bucket, I make time for results, thinking, administration, improvement and relationships.
    • Establish a rhythm of results.  Don't let the tail wag the dog.  Factor your creation cycles from your release cycles.  Your release rate should match absorption rate and demand.  Your production rate doesn't need to be tightly bound to your release.  For instance, you could write your eight blogs posts on Sunday, then trickle out over the week. See Drum-Buffer-Rope.
    • Deliver incremental value.  Chunk it down.  Focus on value-delivered over backlog burndown.  It can be easy to be productive, but ineffective.  Focusing on delivering value, keeps you asking the right questions and making the right calls on priorities.  Remember that backlogs tend to suffer from rot over time.  If you focus on value-delivered, you'll miss less windows of opportunity, or at least you're considering those windows when you prioritize.  The other secret here is that focusing on value can be more energizing than tackling an overwhelming backlog, even if all you really changed is perspective ;)
    • Know the sum is better than the parts.  Consistent action over time produces real results.  Think about how much you've accomplished over the long run, just by showing up at work every day and doing your job.  See How To Overcome Resistance.
    • Improve your network.  Who you spend time with probably has the largest impact on getting results, personal growth, your quality of life ... etc.  Tip - build a mind map of your personal and professional networks and see where you need to tune, prune or plant.
    • Play to your strengths.  Improving your strengths can help you achieve more than improving your weaknesses.  The exception is liabilities.  Reduce the liabilities that hold you back.
    • Reduce your context switching.  Context switching is one of the worst productivity killers. If you're spending more time switching than doing, it's a problem.  Consider how you apply the following software patterns and practices: batching, remote facade, implicit lock, lazy load, coarse-grained lock, proxy, RI and FI, buffers, and Drum-Buffer-Rope.
    • Manage energy for results.  Manage energy, not time for results.  When you're "in the zone," you get results.  How well do you get things done when you're emotionally or mentally drained?  See Manage Energy, Not Time and The Secret of Time Management.
    • Use focus as your weapon for results.  Focus is your friend.  A batched and focused effort can produce amazing results.  Few problems withstand sustained thinking or effort. 30 Day Improvement Sprints, Why 30 Day Improvement Sprints, Making 30 Day Improvement Sprints.
    • Reduce friction.  Create streamlined execution paths.  create a fast path for stuff you need to do frequently.  There's probably a few scenarios where you have more friction in your process than you'd like.  I use 30 Day Improvement Sprints for my perpetual friction points.
    • Use checklists.  I'm a fan of using checklists.  If the air force can use them to avoid task saturation and improve effectiveness, so can I.  See Execution Checklists and How To Avoid Task Saturation.
    • Build a system of profound knowledge.   See The Deming System of Profound Knowledge and Deming's System of Profound Knowledge  This is about thinking of the system as a whole, knowing the impact of changes in the system, focusing on knowledge management, and taking into consideration the people-side of things.  Remember that just because you might not be in a learning organization, doesn't mean that you can't set an example.
    • Do more, think less.  I'm not advocating thoughtless actions.  I'm countering actionless thoughts.   Thoughtful actions produce results.  If you're already acting on your ideas great, otherwise, action is the best oil for rusty results.

    Try the ones you like.  Experiment with the ones you don't.  You might get surprised.  As Tony would put it, "If you do what you've always done, you'll get what you've always gotten". Adopt a growth mind-set over a fixed mind-set.   I'd be interested in hearing success stories or your favorite rituals for results -- what techniques have personally served you well?

  • J.D. Meier's Blog

    Working Memory vs. Routine Activity

    • 6 Comments

     

    Have you ever wondered why some things you can do on "auto-pilot" or without thinking, while other tasks are mentally draining? Your thoughtful tasks are using your working memory (prefrontal context), while your repetitive, familiar and routine activities are using your basal ganglia, which doesn't require conscious thought.

    Prefrontal Cortex and Basal Ganglia
    David Rock and Jeffrey Schwartz summarize the prefrontal cortex and basal ganglia in their article, "The Neuroscience of Leadership", in "strategy+business" magazine:

    • Prefrontal cortex - working memory, the brain's "holding area," where perceptions and ideas can first be compared to other information. Fatigues easily and can hold only a limited around of information "on line" at any one time. Promotes and supports higher intellectual functions. It's particularly well developed in humans and doesn't exist below the higher primates.
    • Basal ganglia - involved by routine, familiar activity. Functions exceedingly well without conscious thought in any routine activity. Any activity conducted repetitively (to the point of a habit) will tend to get pushed down into the basal ganglia. This frees up the processing resources of the prefrontal cortex.

    Example
    You can relate to this using driving a car as an example. When you first learn to drive a stick shift, it's a lot of thinking and processing. You're using a lot of your working memory (prefrontal cortex.) Once you get enough practice, it becomes a habit and you no longer have to think about your driving. At that point, you've baked the routines into your basal ganglia.

    How To Use This
    You can apply this in three ways: First, when you're learning something new, chunk it up so your working memory can handle it. Second, when you are getting overloaded, consider creating a checklist so you can "dump" your working memory. Third, when you are learning a new task and it feels awkward, rather than get frustrated, remind yourself that you're dealing with prefrontal cortex and you haven't move it to your basal ganglia yet.

  • J.D. Meier's Blog

    High-Leverage Strategies for Innovation

    • 6 Comments

    What are the high-leverage strategies that the leaders in innovation use?  In "Smart Spenders, the Global Innovation 1000," an article in strategy+business magazine, Barry Jaruzelski, Kevin Dehoff, and Rakesh Bordia write about the successful strategies that the 94 high-leverage innovators use.

    Example High-Leverage Strategies
    Here's a sampling of the high leverage strategies:

    • Have systematic ideation processes, including involving senior management in the conception and definition of new ideas.
    • Have competence at all stages of your value chain.
    • Involve end-users in your innovation strategy.  Spend a lot of time focusing on  where they work, where they play, where they buy, and where they learn.  This helps to increase your efficiency of your new product introductions.
    • Favor flatter and nimbler management structures that make the innovation process more transparent to your executive team.
    • Keep R&D costs down by keeping R&D focused and closely aligned with your business units.  This allows you to target your R&D efforts to meet specific customer needs versus doing a great deal of early-stage, academic research.
    • Keep an internal innovation engine running efficiently through a core engineering team that designs and developers a variety of product lines (this helps provide common engineering and design as well as actual code reuse.)
    • Place greater value on economies of speed, scope and skill rather than simply economies of scale.
    • Look outside your organization for partners, suppliers and customers for new and innovative ideas.
    • Build capabilities along the innovation value chain to generate significant improvements in return on your research and development spending.
    • Pick the elements to generate a competitive advantage based on your industry, competition and internal capabilities.
  • J.D. Meier's Blog

    Start With Something Simple

    • 6 Comments

    What's the best way to build momentum and get results?  Start with something simple.  Seriously.  I get to see folks who get results and those who don't.  The difference nine times out of ten isn't smarts.  It's simply action.  The smart folks who don't get results, either get stuck in analysis paralysis or add too many dependencies up front.  The folks who get results start taking action and adjust along the way.

    Why This Works
    Starting with something simple works.  It's not that thinking up front doesn't help.  It certainly does.  The problem is, three things can happen along the way:

    • At some point, your thoughts are based on way too many assumptions and you don't know what you don't know.  You then find out too little too late.
    • Somebody faster came along.  While you're thinking, they're doing.
    • In the absence of results, your idea slowly dies inside.

    The best way to fuel your fire is to incrementally get results.  Start with something simple.  Results feed on themselves.  If you start with something small, you'll learn faster and you'll start to adapt.  You'll inform your thinking.

    How To Start
    Start with the smallest thing you can personally do.  If you don't know where to start, here's key questions to help:

    • What's the simplest thing you could do?
    • What could you do today?

    Personally, I find asking what I can do today to be the most effective.  Time is a great forcing function.  It's very easy to cut scope using time.  If you don't respect time, then it's very easy to add way too many things that will never happen.

    Fail Fast
    While starting with something simple helps build momentum, you'll also want to quickly spike on your risks.  You can do this separately, after you have some success under your belt. 

    To fail fast, cut your idea into thin end-to-end slices and test your results.  For example, take one story or usage scenario and try to instantiate it.  Even before you build the solution, simply doing a dry run will reveal a lot of questions you can use to shape your approach.

    The purpose of failing fast isn't to fail.  It's to uncover your risks and pick better paths.

    Self-Start Techniques for the Action-challenged
    If you know your pattern is to think a thought to death before daring make a move, then here's a quick way out.  Here's two proven practices:

    • Find reference examples.  Using time as your friend, and a proven technique as your guide, challenge yourself to find three working examples of your idea, or at least things you can model from.  Reference examples will both speed your learning and keep you inspired.
    • Find a way to share your idea.  Can you share your idea on a slide?  Can you whiteboard your idea and take a picture?  Show it to a friend or two and get some quick, honest feedback.

    Once you get in the habit of just getting started, you'll wonder how you ever got stuck in the first place.

    Success Snowballs
    At the end of the day, nothing succeeds like success.  Success is a snowball, so build on your successes.  Good luck, and get started, on whatever it is that you've been thinking about starting.

  • J.D. Meier's Blog

    Performance Testing Guide Beta 1 is Available

    • 6 Comments

    Today we released our Beta 1 of Performance Testing Guidance for Web Applications Guide.  It shows you an end-to-end approach for implementing performance testing, based on lessons learned from applied use in customer scenarios.  Whether you're new to performance testing or looking for ways to improve your current approach, you'll find insights you can use.

    Contents at a Glance

    • Part 1, Introduction to Performance Testing
    • Part II, Exemplar Performance Testing Approaches
    • Part III, Identify the Test Environment
    • Part IV, Identify Performance Acceptance Criteria
    • Part V, Plan and Design Tests
    • Part VI, Execute Tests
    • Part VII, Analyze Results and Report
    • Part VIII, Performance Testing Techniques


    Chapters

    • Introduction
    • Ch 01 - Fundamentals of Web Application Performance Testing
    • Ch 02 - Types of Performance Testing
    • Ch 03 - Risks Performance Testing Addresses
    • Ch 04 – Core Activities
    • Ch 05 - Managing an Agile Performance Test Cycle
    • Ch 06 - Coordinate Performance Testing with an Iteration-Based Process
    • Ch 07 – Managing the Performance Testing Cycle in a CMMI Environment
    • Ch 08 - Evaluating Systems to Improve Performance Testing
    • Ch 09 - Performance Testing Objectives
    • Ch 10 - Quantifying End User Response Time Goals
    • Ch 11 - Consolidate Various Types of Performance Acceptance Criteria
    • Ch 12 - Modeling Application Usage
    • Ch 13 - Modeling User Variances
    • Ch 16 - Test Execution
    • Ch 17 - Performance Testing Math
    • Ch 18 - Reporting Fundamentals
    • Ch 19 - Load Testing Web Applications
    • Ch 20 - Stress Testing Web Applications

    About Our Team

    • Carlos Farre - Carlos is our performance and security specialist in patterns & practices.  He helps make sure our patterns & practices code follows our performance and security guidance.
    • Prashant Bansode - When Prashant's on a project, you can be sure he's ripping through the technical accuracy and improving the customer focus.  This is the same Prashant from Guidance Explorer, Security Guidance, and VSTS Guidance.
    • Scott Barber - Scott brings his many years of performance testing experience to the table.  If you do performance testing for a living, you probably know his name, his articles and the trails he's blazed.  Scott’s worked with us previously on Improving .NET Application Performance and Scalability.
    • Dennis Rea - Dennis brings his years of editorial experience to the table.  He worked with us previously on our Security Guidance.
  • J.D. Meier's Blog

    How To: Create a “Hello World” WCF Service Using Visual Studio

    • 6 Comments

    Here's a quick step through of using WCF in Visual Studio 2005.  In this case I used a local machine, running Windows 2003, for the service and the client. 

    There's lot of possible paths, and this is just one path through.  I focused on "Hello World" to run through the basic mechanics, but chose a path to touch enough things that might be interesting to explore another day.

    Scenario
    Use Visual Studio 2005 to do a dry run of creating a WCF service hosted in IIS and calling it from a console application on your local development workstation.  (Note that you don't need to host WCF in IIS; for example, you could use a surrogate console application.)

    Preparation
    In my case, I needed the .NET 3.0 components and the WCF extensions for Visual Studio:
    1. .NET 3.0 Runtime Components
    2. WCF and WPF extensions for Visual studio

    Summary of Steps

    • Step 1.  Create the test service
    • Step 2. Add a Hello World Method
    • Step 3.  Test your WCF service
    • Step 4.  Enable meta-data for your WCF Service.
    • Step 5.  Create the test client.
    • Step 6.  Add a Web Services reference to your WCF Service.
    • Step 7.  Add the namespace to your
    • Step 8. Call your WCF service

    Step 1.  Create the test service
    In this step, we'll create a WCF service that uses HTTP bindings, for backward compatibility (non-.NET 3.0 clients)

    1. In Visual Studio, click File -> New Web Site
    2. Select WCF Service
    3. Browse to a directory to store your project: (e.g. D:\Dev\WCF\Test1\Serve )
    4. Enable wsHttpBinding.  To do so, right-click Web.config and click Edit WCF Configuration ... Expand Services > expand MyService -> expand Endpoints.  Click (Empty Name).  Change wsHttpBinding to basicHttpBinding
    5. Create the virtual directory.  In your File Manager, right-click your Server folder (i.e. D:\Dev\WCF\Test3\Server) and click Properties, then Web Sharing, and click Share this folder, then click OK.

    Step 2. Add a Hello World Method
    In Service.cs, you'll add your Hello World method:

    1. Add the HelloWorld operation contract below public interface: [ServiceContract()]
      public interface IMyService
      {
          [OperationContract]
          string MyOperation1(string myValue1);
          [OperationContract]
          string MyOperation2(DataContract1 dataContractValue);
          [OperationContract]
          string HelloWorld();
      }
    2. Add your HelloWorld method below public class MyService : public class MyService : IMyService
      {
          public string MyOperation1(string myValue1)
          {
              return "Hello: " + myValue1;
          }
          public string MyOperation2(DataContract1 dataContractValue)
          {
              return "Hello: " + dataContractValue.FirstName;
          }
          public string HelloWorld()
          {
              return "Hello World";
          }
      }

    Compile and debug any errors.
    Step 3.  Test your WCF service

    1. In IIS Manager, under Default Web Site, right-click expand Server (the virtual directory you just created)
    2. Right-click Service.svc and click Browse

    There's two issues you might hit here:

    1. You don't have ASP.NET installed/enabled.  To fix this, first run aspnet_regiis /i from your .NET installation directory (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727)  Then, allow ASP.NET in your IIS Manager.  To do so, in IIS Manager, expand Web Service Extensions, select ASP.NET v.2.0.50727 and click Allow.
    2. You might see "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service."  To fix this, first enable anonymous access.  In IIS Manager, right click your v-dir (Server), click Properties, click Directory Security, click Edit under Authentication and Access control, click Enable Anonymous Access, then OK your way out of the dialogues.  Next, recycle IIS.  In a command prompt, type IISreset.  If successful, when you browse your Service.svc file from IIS Manager (e.g. http://localhost/service/service.svc). you'll get a message that starts with the following:
      This is a Windows© Communication Foundation service. 
      Metadata publishing for this service is currently disabled.

    Step 4.  Enable meta-data for your WCF Service.

    1. In VSTS, right-click Web.config and click Edit WCF Configuration.  In WCF Configuration, expand Advanced, then expand Service Behaviors, then
      right-click returnFaults and click Add Service Behavior Element Extension.  Select serviceMetadata and click Add
    2. In WCF configuration, select serviceMetadata and change HttpGetEnabled to True.  Close the dialogue and save changes.
    3. Test your service again.  Browse to http://localhost/Server/Service.svc and this time you should see your service (e.g. MyService Service).  You
      will see a message that starts with the following:
      "You have created a service."

    Step 5.  Create the test client.
    In this step, we'll create a quick console app to call the WCF service:

    1. In Visual Studio, click File -> New -> Project
    2. Select Console Application.
    3. Browse to a directory to store your test client:  (e.g. D:\Dev\WCF\Test1\WCFClient)

    Step 6.  Add a Web Services reference to your WCF Service.
    In this step, we'll add a Web Services reference. 

    1. Right-click References      
    2. Click Add Web Reference ...
    3. In the Add Web Reference dialogue, add the path to your WCF Service (http://localhost/Server/Service.svc)
    4. Click Add Reference to close the dialogue.  You should then see your Web Service reference show up under Web References.

    Step 7.  Add the namespace to your   

    1. Browse to your Reference.cs file.  You'll find the file below Reference.map under your Web service reference.  You might need to click the Show All Files button on the Solution Explorer so you can see the files under your Web service reference. 
    2. Find the namespace.  You'll see a line similar to the following:
              namespace ConsoleApplication1.localhost
    3. Add the using statement to your Program.cs file.
                      using ConsoleApplication1.localhost;

    Step 8. Call your WCF service
    In your test client, call your WCF service:
            static void Main(string[] args)
            {
                MyService service = new MyService();
                string foo;
                foo = service.HelloWorld();
                Console.WriteLine(foo);
            }
    When you compile and run your console application, you should see the following:
    Hello World
    Press any key to continue . . .

    Additional Resources

    Hopefully this step through helps you quickly see some of the bits and pieces you can play with.

  • J.D. Meier's Blog

    Videos: Security, Performance Testing, and Visual Studio Team System

    • 6 Comments

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

    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.

    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.

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

    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.

  • J.D. Meier's Blog

    Growth Mind-set Over Fixed Mind-set

    • 6 Comments

    Do you have to be great at everything?  If this stops you from doing things you want to try, then it's a limiting belief.  Scott Berkun spells this out in Why You Should Be Bad at Something.

    Keys to Growing Your Skills
    Here's a set of practices and mind-sets that I've found to be effective for getting in the game, or getting back in the game, or learning a new game versus just watching from the side-lines. 

    • Swap out a fixed mind-set with a growth mind-set. (innate ability vs. learning) See The Effort Effect.
    • Call it an "experiment."  This sounds like a trivial frame game, but I see it work for myself and others.
    • Treat perfection as a path, not a destination.  If you're a "perfectionist," (like I "was", er "am, er ... still fighting it), you know what I mean.
    • Use little improvements over time.  Focus on little improvements and distinctions over time, versus instant success.  It's consistent action over time that produces the greatest results.  You're probably a master of your craft, whatever it is you do each day, every day.  John Wooden focused his team on continuous, individual improvement and created the winningest team in history.
    • Remind yourself you're growing or dying.  You're either climbing or sliding, there's no in-between (and the slide down is faster than the climb up!)
    • Try agin.  If at first you don't succeeed, don't just give up.  Remember folks like Thomas Edison, who "failed" many, many times before finding "success" (it's a part of innovation)
    • Focus on lessons over failures.  Remind yourself there are no failures; only lessons (one more way how "not" to do something)
    • Fail fast.  The faster you "fail", the faster you learn.
    • Don't take yourself or life too seriously.  If you take yourself too seriously, you'll never get out alive!
    • Learn to bounce back.  It's not that you don't get knocked down, it's that you get back up.  (Just like the song, "I get knocked down, but I get up again")
    • Give yourself time.  A lot of times the difference between results is time.  If you only chase instant successes, you miss out on opportunities. Walk, crawl, run.  Or, if you're like me, sprint and sprint again ;) 
    • Start with something small.  Build momentum.  Jumping an incremental set of hurdles is easier than scaling a giant wall.   
    • Build on what you know.  Now matter where you are or what you do, you take yourself with you.  Bring your game wherever you go. 
    • Learn to like what growth feels like.   I used to hate the pain of my workouts.  Now, I know that's what growth feels like.  The better I got at some things, the more I hated how awkward I was at some new things.  Now I like awkward and new things.  It's growth.
    • Find a mentor and coach.  It doesn't have to be official.  Find somebody who's great at what you want to learn.  Most people like sharing how they got good at what they do.  It's their pride and joy.  I used to wonder where the "mentors" are. Then I realized, they're all around me every day.
    • Have a learning approach.  For me, I use 30 Day Improvement Sprints.  Timeboxes, little improvements at a time, and focus go a long way for results.  I use 30 Day Improvement Sprints.

    There's a lot more I could say, but I think this is bite-sized working set to chew on for now.

    More Information

    • The Effort Effect - This article exposes the truth behind "you can't teach an old dog new tricks" and whether all-stars are born or made (nature vs. nurture.)  If you have kids, this article is particularly important.  Adopting a growth mind-set over a fixed mind-set can have enormous impact.

    My Related Posts

  • J.D. Meier's Blog

    Collection Pools

    • 6 Comments

    How do you store your notes and reference information in a way that’s low overhead and easy to find?  The key is to created a limited set of places to look that you trust.   I use a small set of what I call Collection Pools.  I think of them as pools because they’re effectively pools of reference information I draw from.

    Collection Pools
    I currently use the following pools:

    • Notes
    • Quick Stuff
    • Thoughts

    I create a folder in Outlook for each pool and I create posts in the folders.  It’s flat by design.  I could just as easily use a folder  on my hard drive with text files, but I like the preview pane in Outlook and sometimes the rich text helps.

    Using the Pools
    Here's how I use the pools:

    • Notes is where I store the majority of my reference information which is anything from a meeting recap to notes from a Web page.  It’s one long flat list of posts, ordered by time.  I can quickly sort by title or search for a keyword.  I used to use a local Wiki, but I find a flat lists of posts to be really lightweight and effective.  Scrolling through my notes is great with the preview pane in Outlook.
    • Quick Stuff is where I keep a lot of common lookup information and indexes, such as favorite links, lab machine names, distribution lists … etc.
    • Thoughts is where dump my ideas and distinctions I make throughout the day.  It’s my pool of insights.  It’s a very light-weight way to journal my ideas and distinguish my insights from the rest of my reference notes.

    Results
    I actually started with my Notes and Quick Stuff folder a few years back.  I thought it would be a temporary solution while I explored options.  It turned out to be the most efficient approach of all the various ways I tried.  I always knew where to put things and I always knew where to look and it was always open.  I added the Thoughts folder in February this year.  It too turned out to be the most efficient approach I have for a scannable set of ideas and insights and I like the ability to scroll through time.

    While there’s a lot of fancier things I could do, simple text notes chunked up in a few folders is a pretty efficient system.  I think the lesson here is that for a practice to stick over time, it has to be simple enough and effective enough.  Otherwise, it fails the test of time. 

    My Related Posts

  • J.D. Meier's Blog

    patterns and practices Visual Studio Team System Guidance Now Available

    • 6 Comments

    This is our first release of our Visual Studio Team System Guidance.  This project is a collaborative effort with VSTS team members, customers, field, and industry experts.

    What you'll see so far, is Practices at a Glance and Questions and Answers as we're tackling source control / versioning.  They are designed to give you a quick path through the lessons learned and emerging practices.  These are works in progress.  As we learn, we update.  What you'll also see is a section that includes artifacts we create to help us build the guidance.  You'll also see a Team System Resources Index which is lists of the various public resources we use.  One of the first things steps we took to ramp our team, was gather and catalog the available resources.  There are a lot!

    Once we tackle source control, we'll be moving through other high priority areas, such as build, work items, and reporting.   We're evaluating customer success using scenarios, organized as Scenario Frames.  Here's our emerging Source Control Scenario Frame. The working plan at this point is to build community around our Visual Studio Team System Guidance, while we tune and prune our guidance.  We have a fast publishing path in CodePlex and we can experiment with usability and various guidance form factors.  As the guidance matures, we can make key guidance broadly available in the MSDN library.

    Our team includes previous members from security and performance guidance: Alex Mackman, Jason Taylor and Prashant Bansode.  We're working closely with Jeff Beehler, Rob Caron, Graham Barry, and Bijan Javidi on the VSTS side to bring you the guidance you need.  Send your feedback, fan mail and hate mail to VSGuide@microsoft.com

  • J.D. Meier's Blog

    More Effective Feed Reading

    • 6 Comments
    I want more from the information that's out there today. I want to spend less time hunting and gathering it, and more time acting on it. I want to find the information that gives me an edge. Most importantly, I want to avoid the "free shopping spree" pattern, where if I grab it all as I go, I may not get the most value for my time.

    As I talk to more feed readers, I find there's patterns that work and patterns that don't. I'm a fan of starting with examples of "what's working" and "what's not" before building a new solution. The most common anti-pattern I found was "too many feeds, not enough time." The most effective pattern I found was a set of tuned and pruned feeds.

    To fix my feeds, I used the following approach:

    1. Started with a clean slate.
    2. Figured out my objectives (what do I want to know? what would I do with the information?)
    3. Figured out my constraints (how much time and how many feeds?)
    4. Hunted and gathered for the most effective feeds.

    To wipe my slate clean, I archived what I had. I had several hundreds of feed sources. I figured I could compare later, but I wanted to start fresh and lose potential baggage.

    To figure out my objectives, I asked a simple question -- "what do I want to accomplish?" I figured listing the questions I need to answer with my feeds would be the most effective:

  • What are new ideas, insights or techniques I can use in my day to day?
  • What's going on in my immediate circle? (my stuff, friends, family, teams … etc.)
  • What are the influencers up to? (Business, tech, ... etc.)
  • What's the blogosphere and social software up to? (Technorati, Delicious, ... etc.)
  • What's going on in software engineering?
  • What new insights will change the world?
  • What's Google, Microsoft, Yahoo, IBM, and Apple doing?

    This created my map of what feeds I needed to add. I ended up surprised by how different my deliberate map was than my typical feed reading habbits. I didn't realize this until I had the map above to check against.

    Next, I figured out practical time and quantity constraints. I set a bar of 30 feeds and a max of 20 minutes reading time max for reading time. Talk about a true exercise in prioritization, considering I'm used to hundreds of feeds! I decided I want to trade lightweight and effective over exhaustive and a burden. Put it another way, I want to spend more time with the cream of the crop, and less time filtering the wheat from the chaff.

    As I hunted and gathered for feeds, I distinguish sources of news from sources of insight. I want both but I prioritize insight. I also looked for bloggers that take the time to distill information for some key areas, so that I don't have to. In some areas, I do my own distillations, in others, I want to leverage the network effect. As I hunted for feeds, I also kept the following guiding questions in mind:

  • How to minimize my time, while maximizing results?
  • How to cast a wide enough radar to see beyond what's right in front of me?
  • How to use checks/balances for the information I see?
  • How to keep a stream of information to build anticipation and foster innovation?

    This gave me a good baseline of feeds. It also put me in great shape to bring over some of my favorite feeds I had archived. It was easier to bring over just a handful of the best vs. sort and filter through everything I had.

    While this wasn't my first do-over, it was probably my most useful. I feel closer to the sources of information that I'm actually going to use, and less burdened by the noise. I'm going to test more tools and techniques for feed reading, so if you have any tips or techniques to share, I'd like to hear them.

  • J.D. Meier's Blog

    7 Habits of Highly Effective Program Managers

    • 6 Comments

    What does it take to be an effective Program Manager at Microsoft?  I'm responding to some requests for my take on what it takes to be an effective PM.  I figured I could use a familiar 7 habits approach to help frame out a start. 

    To pick a set of habits, I started with a set of reference examples.  I used the most effective and ineffective PMs that I've seen over time.  I considered their track record, their ability to influence, and their leadership skills.  Most importantly I looked at their ability to ship and make the right impact for customers.  Next, I looked for the underlying patterns (I'm a principles, practices and patterns guy).  I used the ineffective PMs to think of the anti-patterns and the practices of what not to do.  This contrast helped me clarify the distinctions between effective and ineffective.

    Here's what I found to be the 7 habits of highly effective program managers:

    • Habit 1, Frame problems and solutions.
    • Habit 2, Sell visions.
    • Habit 3, Deliver incremental value.  
    • Habit 4, Manage communication.
    • Habit 5, Connect with customers.
    • Habit 6, Execute. 
    • Habit 7, Leverage the system.

    Habit 1, Frame problems and solutions.  Frames are the things mental models, metaphors, and conceptual frameworks are made of.  Simply put, they're frames of reference.  Effective PMs create useful ways of looking at the problems and solutions.  They create shared frames of reference that help narrow and focus, while keeping perspective.  Frames help chunk up the problem or the solution.  Frames also help share information quickly as well as avoid information overflow.  The secret here is that frames provide contextual reference.  Without context, it's hard to evaluate problems or solutions.    

    Habit 2, Sell visions.  The most effective PMs dream up great ideas and they sell them.  They sell them in the hall, they sell them to co-workers, they sell them up the chain.  They have an elevator pitch that resonates.  They can paint a vivid picture of how the world will be different.  Sometimes a PM has an idea that people aren't ready for.  Sometimes a PM has an idea they just aren't selling right.  Sometimes a PM has an idea that ... well ... just isn't ready for market or planet Earth.  Selling visions involves both thought leadership and people leadership.  I think the secret here is effective PMs sell visions by answering "what's in it for you" for stakeholders and customers.

    Habit 3, Deliver incremental value.   How do effective PMs go from zero to Rome?   While the big bang can make a lot of impact, the problem is the longer they delay, the more project risk adds up over time -- visions change, people change, markets change, stakeholders change, perceptions change … etc.   Anything that isn't built in a day needs a serious chunking strategy.  The sooner they can start delivering value, the sooner they can get feedback and adapt and change.  Also, they have better chances of hitting key windows of opportunity. 

    The most effective PMs can chunk their solutions.  This is non-trivial, particularly in software.  It means knowing what the minimum shippable chunk is.  It means right-sizing their chunks so that each one delivers value for the right customers.  It means unbundling dependencies to remove unnecessary project risks.

    I think the secret of effective PMs here is thinking in terms of value rather than quantity, as well as knowing dependencies.  What can they cut and truly gain time and resources without risking quality?  Here's a true test ... if their 12 month project were cut into 6 ... or their 6 month project cut into 3 ... what would they cut and what would they deliver?  If the success of their project depends entirely on shipping everything in their plan for the full project cycle, that's a recipe for failure. 

    Habit 4, Manage communication.  This is a crucial skill since this means managing perceptions, managing expectations,  brokering knowledge, and making sure the right people are involved.   This is why some PMs fail where others succeed.  The most effective PMs make sure the right people are involved on the right problems.  They also setup forums and channels for communication.  I think there are a few secrets here.  The first secret is, they tailor the language for their audiences.  For example, for stakeholders, they know their relevant currency (time? budget? resources? business value?).  For engineers, maybe it's how does it work or why.  For customers it might be features, scenarios or value.  The second secret is, they use a variety of communication tools.  Effective PMs make use of a range of SharePoint portals, Wikis, Mind Maps, whiteboards, blogs, forums, etc.  The third secret is, they use the right mediums for the message.  Effective PMs consider whether their message is best delivered in slides, mail, meeting, phone, etc.  For example, slideware is often more effective than a long email. 

    Habit 5, Connect with customers.   This is where the rubber meets the road.   The most effective PMs have strong customer connections.  Not only do they work with customer directly, but they have a useful representation across relevant segments.  The mistakes I usually see here include the following: no customers, pretend customers, one customer size fits all, or assuming their internal scenario can be generalized to typical customer scenarios.  The secret here is that it is not the number of customers, rather it is scenario representation and trusted sounding boards with key customers.

    Habit 6, Execute.  Execution makes life easier at Microsoft.  The most effective PMs have great work breakdown structures and the right resources working on the right jobs.  I know this sounds overly simple, but there's a secret here.   I've seen work breakdown structures that are focused on activities versus outcomes.  If a PM does not have a good work breakdown structure, then that means they don't know the work to be done.  If they don't know the work to be done, then their estimates are off.  If they don't have a good work breakdown structure, then it's also easy to have the wrong people doing the wrong jobs.

    Habit 7, Leverage the system.  Effective PMs know the system they are operating in.  For example, they know their product cycle, software development life cycle, key milestones, and key events.  They also know who or what influences who.  Basically, they know how the system works.  While they could paddle down the river without a map, this map helps them anticipate the obstacles and opportunities.  The secret here is that experience alone doesn't create this map.  Anybody can start making their own map by asking questions about the system they're working in.

    While this list of habits above is not a comprehensive list, I thought it would be a good start.  I'd actually like to hear from you what you think are the habits of the most effective PMs.

  • J.D. Meier's Blog

    MUST vs. SHOULD vs. COULD

    • 6 Comments

    Whether I'm dealing with software requirements, or I'm prioritizing my personal TO Dos, I think in terms of MUST, SHOULD, COULD.  It's simpple but effective.

    Here's an example of some scenarios and usage:

    • getting a quick handle on my day - what MUST I do today?  what SHOULD I do?  What COULD I do?
    • prioritizing my personal backlog - what MUST I do today?  what MUST I do this week?  What should I do? What could I do?
    • focusing my teams - what MUST we release this week?  What SHOULD we release this week?  what COULD we release this week?
    • brainstorming sessions - what COULD we do?  What SHOULD we do? what MUST we do?
    • determining an incremental release - what are the MUSTs for this software release?  What are the SHOULDs?  What are the COULDs?
    • helping a customer identify their security objectives - What security constraints MUST be met for this software?
    • helping a customer identify their performance objectives - what performance constraints MUST be met for this software?

    It's easy to get lost among SHOULDs and COULDs.  I find factoring MUSTs from the SHOULDs and COULDs helps get clarity around immediate action.

  • J.D. Meier's Blog

    OpenHack 4 (eWeek Labs): Web Application Security

    • 6 Comments

    Whenever I bring up the OpenHack 4 competition, most aren't ware of it.  It was an interesting study because it was effectively an open "hack me with your best shot" competition. 

    I happened to know the folks on the MS side, like Erik Olson and Girish Chander, that helped secure the application, so it had some of the best available security engineering.  In fact, customers commented that it's great that Microsoft can secure its applications ... but what about its customers?  That comment was inspiration for our Improving Web Application Security:Threats and Countermeasures guide.

    I've summarize OpenHack 4 here, so it's easier for me to reference.

    Overview of OpenHack 4
    In October 2002, eWeek Labs launched its fourth annual OpenHack online security contest.  It was designed to test enterprise security by exposing systems to the real-world rigors of the Web.  Microsoft and Oracle were given a sample Web application by eWeek and were asked to redevelop the application using their respective technologies. Individuals were then invited to attempt to compromise the security of the resulting sites.  Acceptable breaches included of cross-site scripting attacks, dynamic Web page source code disclosure, Web page defacement, posting malicious SQL commands to the databases, and theft of credit card data from the databases used.

    Outcome of the Competition
    The Web site built by Microsoft engineers using the Microsoft .NET Framework, Microsoft Windows 2000 Advanced Server, Internet Information Services 5.0, and Microsoft SQL Server 2000 successfully withstood over 82,500 attempted attacks to emerge from the eWeek OpenHack 4 competition unscathed.

    More Information

    For more information on implementation details of the Microsoft Web application and configuration used for the OpenHack competition, see "Building and Configuring More Secure Web Sites: Security Best Practices for Windows 2000 Advanced Server, Internet Information Services 5.0, SQL Server 2000, and the .NET Framework"

  • J.D. Meier's Blog

    Best Practices on the patterns & practices Team

    • 6 Comments

    The Microsoft patterns & practices team has been around since 2000. The patterns & practices team builds prescriptive guidance for customers building applications on the Microsoft platform.  The primary mission is customer success on the platform.  As part of that mission, patterns & practices delivers guidance in the form of reusable libraries, in-tool experiences, patterns, and guides.  To put it another way, we deliver code-based and content-based guidance.

    I’ve been a part of the team since 2001.   Along the way, I’ve seen a lot of changes as our people, our processes, and our catalog of products have changed over time.  Recently, I took a step back to collect and reflect our best practices.  Some practices were more effective than others, we’ve added some new ones, and we’ve lost some along the way.  To help reflect and analyze the best practices, I created a map of the key practices organized by discipline.  In this post, I’ll share the map (note that it’s a work in progress.)  Special thanks to Ed Jezierski, Michael Kropp, Per Vonge Nielsen, Shaun Hayes, and Tom Hollander (all former patterns & practices team members) for their contributions and insights to the map.

    Best Practices by Discipline
    The following table is a map of the key practices used by the patterns & practices team over the years.

    Discipline Key Practices
    Management Team
    • Milestone Reviews
    • Product Portfolio (correlated with customer & business challenges/opportunities)
    • Team development  (leadership skills, communication skills, … etc.)
    • Backlog
    • Connection with customers and partners
    • Fireside chats
    • Meeting with key stakeholders in the app plat space
    • People review
    • Scorecard management
    • Tracking overall team budget
    • Weekly Status
    Architect
    • Articulate the inner (scope) and outer (context) architecture (these involve time)
    • Articulate technical principles - drive technical tradeoffs discussions
    • Be aware of roadmaps of the company, and build trust to make sure they are current
    • Be familiar with competitive tech.
    • Customer connection.
    • Groups’ technical strategy and product model.
    • Know actionable industry trends.
    • Overall design with functional breakdown.
    • Relationship with key influencers in the product groups.
    • Spikes / explorations including new approaches (technology and process)
    • Technical challenges
    Development Team
    • Ship running code / guidance at the end of each iteration
    • User Stories
    • XP / Scrum with test-driven-development
    • Continuous build and integration
    • Iterations
    • Retrospectives
    Product Management
    • Asset Model
    • Customer Surveys (feature voting, exit polls)
    • Standardized product model (app blocks, factories, guides, etc.)
    • Blogging throughout project (planning, development, release)
    • Case Studies
    • Community Lead
    • Customer Advisory Board
    • Customer Proof Points
    • Own Vision / Scope
    • Portfolio Planning
    • Project dashboard
    Program Management
    • Customer Connected Engineering (CCE)
    • Fix-time, Flex Scope
    • Scenarios / User Stories
    • 5 customers stand behind it
    • AAD Sessions (Accelerated Analysis and Design)
    • Backlog
    • Exec Sponsor
    • Product owner from M0 (Milestone 0)
    • Quality over scope
    • Scorecards
    Release Checklist
    • Release Checklist
    • Release Mail
    Test Team
    • Automated tests
    • Focused on overall quality (functionality is tested by dev)
    User Experience Team
    • Authoring Guide (Key practices for authors)
    • Content Spec (Content scenarios and outline)
    • Doc Tool (Template for standardizing content formatting)

    Some practices are obvious, while some of the names of the practices might not be.  For example, “Fireside chat” is the name of our monthly team meeting, which is an informal gathering and open dialogue.   I may drill into some of these practices in future posts, if there’s interest and there are key insights to share.

  • J.D. Meier's Blog

    Now Available - The Second Batch of Enterprise Library 5.0

    • 6 Comments

    The second batch of releases for patterns & practices Enterprise Library 5.0 (EntLib) is now available on MSDN.  This release includes the following:

    The main sites for Enterprise Library and Unity are:

  • J.D. Meier's Blog

    The Power of Patterns and Practices

    • 6 Comments

    I wrote a post, The Power of Patterns and Practices, on Sources of Insight to summarize some of the benefits of using patterns and practices as a way to organize and share knowledge.  For simplicity, I think of patterns as a way to share problem and solution pairs in context.  I think of practices as a way to share methods or techniques.   When you combine them, you effectively have an efficient way to share strategies and approaches for success in a given domain. 

    While sharing patterns and practices has been effective in software, I think other industries can gain from finding ways to more effectively share patterns and practices.   Christopher Alexander, father of the pattern language movement, set a great example by creating a catalog of patterns for towns, buildings, and construction in the architecture space.  Along those lines, Michael Michalko, a former Disney imagineer, put together an amazing catalog of patterns and practices for creative thinking, in his book, THINKERTOYS.  The meta-point is that when you frame and name things, you simplify sharing knowledge in a meaningful and scalable way.

  • Page 4 of 43 (1,069 items) «23456»