J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Layers and Tiers

    • 2 Comments

    As part of the patterns & practices App Arch Guide 2.0 project, we needed to nail down layers and tiers.   

    Layers vs. Tiers
    The original App Arch Guide distinguished between layers and tiers:

    "This guide uses the term layer to refer to a component type and uses the term tier to refer to physical distribution patterns."

    In other words, layers are logical and tiers are physical (two-tier, three-tier, N-tier).  This distinction is helpful, particularly when you want to talk about where you run your layers (which tier).

    Presentation Layer, Business Layer and Data Layer
    While there's some variations in layer terms, many people that build application will identify with presentation, business, and data layers.  Here's an example:

    Layers 

    • Presentation Layer - provides interactive access to the application.  (You could argue that user interaction layer might be more appropriate.)
    • Business Layer - the logical grouping of components and services that provide the business functionality in your application.
    • Data Layer - the logical grouping of the components and services that provide data access functionality in your application.  (You could argue to call it your resource access layer.)

    Two-Tier, Three-Tier, and N-Tier
    As mentioned earlier, you can think of tiers as physical distribution patterns.   Here are some visual examples:

    Two-Tier

    2Tier

    Three-Tier

    3Tier 

    N-Tier

    NTier

    Additional Resources
    Here's some links you might find useful:

    My Related Posts

  • J.D. Meier's Blog

    Tags vs. Categories

    • 5 Comments

    What's the difference between tags vs. categories in your blog?  A lot.  Knowing the difference between tags and categories can help you better structure your blog for browsing and SEO.  Personally, I hadn't noticed the issue before because I only have tags on my MSDN blog.  As part of my research on effective blogging practices, I hit the issue.  Now that I've experimented with a few blogging platforms, the difference between tags and categories is more obvious.  For example, WordPress 2.3 supports tags in addition to categories.

    Categories, Internal Tags and External Tags

    • Categories. Categories are your high-level buckets.  You should be able to chunk up your blog by a small, mutually exclusive set of categories.  Imagine a user trying to browse the broad themes of your blog.  Categories can also become part of your URL.
    • Internal tags.  Internal tags are for finer-grained slicing and dicing and hopping across your categories.
    • External tags.  External tags, such as Technorati and del.icio.us are for showing your conent in the relevant topics and niches at Technorati and del.icio.us.

    Tag Clouds
    I think the big benefit of tags is creating browsable tag clouds where you can discover related content.  Whereas categories are just one topic, you can use tags to find related content.  For example, you might browse a "security" tag and then browse a "performance" tag to find the intersection of content tagged both "security" and "performance".

    Notes from Lorell
    In Categories versus Tags - What’s the Difference and Which One?, Lorelle makes the following points:

    • "Categories help visitors find related information on your site. Tags help visitors find related information on your site and on other sites."
    • "Categories generate a page of posts on your site. Tags can, too, but often generate a page of off-site posts on an off-site website".
    • "Tagging gives you topical search capabilities for your site that are a middle ground between categories and all-out search, but it shouldn’t replace categories entirely."
    • "Should tags replace categories? Absolutely not."
    • "I use categories as broad groups of posts and tags as micro-groups of posts, helping narrow down the interest."
    • "Tags shouldn’t replace categories, but they can help the user and search engines and directories find and catalog related information on your site."

    Notes from Problogger
    In Using Categories and Tags Effectively on Your Blog, Michael Martin makes the following points:

    • "The number of categories should be small."
    • "Each post goes into one category."
    • "Use the same tags over and over again."
    • "The tag cloud is easy to scan."

    The End in Mind
    In the ideal scenario, to use tags and categories more effectively (assuming your blogging platform supports it), you would have the following in place:

    • A small set of categories for browsing the key themes of your site and for helping SEO (by having relevant category names in the full URL.)
    • A nice tag cloud that helps users browser your site more like a topical search -- using words that your users would know and be looking for.
    • Posts tagged with Technorati and del.icio.us tags that match the most relevant niches.

    Turning It Into Action

    • Use categories to divide your blog into a small set of mutually exclusive buckets.
    • Use internal tags for slicing your content in more granular ways and to create tag clouds for your users.
    • Tag your posts with external tags for Technorati and del.icio.us to reach the relevant social circles.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Why Do You Do What You Do?

    • 1 Comments

    One of the keys to making impact is knowing "why" you do what you do?  Chasing the "what" can be a red herring.  It's living your"why" and "how" that helps you be your best and it's where your inner strength comes from.  Most importantly, it's where you give your best where you have your best to give.  One of the tools for figuring out why you do what you do is the Golden Circle.  You can watch this video interview with Simon Sinek on the Golden Circle for an overview.   I also shared my Golden Circle results in my post, Why Do You Do What You Do? on Sources of Insight as both a reminder and inspiration.  Enjoy!

  • J.D. Meier's Blog

    The Power of Blue Books for Platform Impact

    • 12 Comments

    WhyBlueBooksForPlatformImpact

    Why invest in prescriptive guidance or “Blue Books” for Microsoft platform impact?  While the answer is obvious to many, it’s not as obvious to others, so I’ll attempt to paint the picture here.

    Building Secure ASP.NET Applications was the first “blue book” at Microsoft, but it was Improving Web Application Security that really made people take notice (it was downloaded more than 800,000 times in its first six months and it changed how many people in the industry thought about security and it changed their approach.  It’s also the guide that helped many customers switch from Java to .NET.)  An interesting note about Building Secure is that the Forms Authentication approach was baked into the Whidbey platform (ASP.NET 2.0.)

    Blue Books Shape Platform Success
    Blue Books have played a strategic role in both shaping the platform and driving exponential customer success on the platform.   They’ve helped us find and share platform best practices, create mental models and conceptual frameworks, and create systems and approaches that scale success and create powerful ecosystems.  They’ve also helped us spring up offerings for our field, reduce support costs, and win competitive assessments.

    Ultimately, Blue Books give us a strategic look at platform pain points as well as competitive analysis, and a consolidated set of success patterns to run with.

    From patents to methodologies to better ways for better days, “Blue Books” have been the definitive way for improving platform success in a sustainable way – a durable backdrop that provides continuity of the platform over time.

    Benefits at a Glance
    Here is a quick rundown of some of the key ways that Blue Books have helped Microsoft and customers win time and again:

    • Platform Playbooks - Serve as platform playbooks for Microsoft, field, support, customers, and partners
    • Shaping the Platform and Tools – Shape the platform and tools by testing out patterns and practices as well as methodologies and methods with the broad community before baking into the platform and tools.
    • Scaling Success Patterns - Broadly scale proven practices and success patterns for predictable results
    • Roadmaps for Platform Adoption - Lay out roadmaps for technology adoption as well as success patterns
    • Competitive Wins - Win competitive assessments (the Blue Books have played a critical role in influencing industry analysts and in winning competitive assessments time and again)
    • Innovation for Exponential Success - Innovate in methodologies and methods for exponentially improving customer success on the platform
    • Frame and Name the Problem Domains – Frame out and name the problem spaces and domains (when you frame out and name a space, whether through patterns or pattern languages, you create a shared vocabulary and model that empowers people to make forward progress at a faster pace and more deliberate way.)

    The list goes on, but the essence is that these playbooks help customers make the most of the platform by sharing the know-how through prescriptive architectural guidance.

     

    Example Blue Books
    I won’t speak for all the Blue Books at Microsoft, but since I created the bulk of the Blue Books, it’s easy for me to speak from the ones I created.   Here is a summary of the impact that can help you better understand the value of Blue Books from a broader perspective.

     

    Blue BookResults
    Application Architecture Guide, Second Edition
    • The platform playbook for Microsoft’s application platform
    • Canonical application types for Web app, RIA, Rich Client, Mobile, and Web Services
    • Baseline best practices for application architecture and design
    • Templates baked into Visual Studio
    • Praise from Ray Ozzie
    • Praise from Grady Booch
    • Conceptual Framework for Application Architecture
    Building Secure ASP.NET Applications
    (aka The first official Microsoft “Blue Book”)
    • End-to-End Application Scenarios for Web Apps
    • Created a highly reusable set of Application Patterns
    • Baseline architectures and success patterns shared broadly inside and outside Microsoft
    Improving .NET Application Performance and Scalability
    (aka “Perf and Scale”)
    • Repeatable performance model
    • Created a highly-effective method for performance modeling
    • Performance Engineering approach baked into Visual Studio
    • 4 patents filed for performance engineering
    • Performance Engineering approach widely adopted inside and outside Microsoft
    • Used for offerings in Microsoft Consulting Services
    • Rules baked into Microsoft Best Practices Analyzer Wizard (MBPA)
    Improving Web Application Security
    (aka “Threats and Countermeasures”)
    • Repeatable security model for Web applications
    • Created a highly-effective method for threat modeling
    • Created a knowledge base of threats, attacks, vulnerabilities, and countermeasures
    • Security model for network, host, and application security
    • Security Engineering approach baked into Visual Studio
    • 4 patents filed for application security
    • Used for offering in Microsoft Consulting Services
    • Rules baked into Microsoft Best Practices Analyzer Wizard (MBPA)
    Improving Web Services Security
    • Security model for Web Services
    • End-to-End Application Scenarios for Web Services
    • Created a highly reusable set of Application Patterns
    • Baseline architectures and common success patterns shared broadly inside and outside Microsoft
    Performance Testing Guidance for Web Applications
    • Created a highly-effective method for performance testing Web applications
    • Performance Testing approach widely adopted inside and outside Microsoft
    • Used for offerings in Microsoft Consulting Services
    Security Engineering Explained
    • Created a model for baking security into the life cycle
    • Helped shift thinking from security "reviews" to "inspections"
    • Overlays security-specific activities on product development life cycles
    Team Development and Visual Studio Team Foundation Server
    • Created a glide-path for TFS adoption (source control, build, task tracking / reporting, process)

     

    End-to-End Application Scenarios and Solutions
    Here’s an example of an application scenario.  We use application scenarios to show how to solve end-to-end problems.  It’s effectively a baseline architecture based on successful solutions.   Here is an example from our WCF Security Guide:

    Scenario

    ExampleScenario

    Solution

    ExampleSolution

     

     

     

    We share them as sketches like on a whiteboard so they are easy to follow.

    Methodologies and Methods
    Methodologies, frameworks and approaches are nice ways to wrap up and package a set of related activities that you can use a baseline for your process or to overlay on what you already do.  Methods are step-by-step techniques for producing effective results and they are a powerful way to share expertise.   Methodologies and methods are how we create exponential results and amplify our impact.

    Example Methodology – Agile Security Engineering

    ExampleMethodologyAgileSecurityEngineering

    Example Method – Threat Modeling Technique

    ExampleMethodThreatModeling

     

    Conceptual Frameworks and Mental Models
    We use mental models, conceptual frameworks, and information models to learn and share the problem space.

    Example Conceptual Framework for Web Security

    ExampleConceptualFramework

    Example Mental Model for Application Architecture

    ExampleMentalModelAppArch

     

    Hot Spots
    Hot Spots are basically heat maps of pain points and opportunities.  We use them as a lens to help us see customer pain points and opportunities, and to prioritize our investments.  They also help us identify, organize, and share scenarios.  Hot Spots also help us organize and share principles, patterns, practices, and anti-patterns for key engineering decisions.   Hot Spots are a powerful tool for product planning and for building prescriptive guidance, platform, and tools.

    Example of Security Hot Spots

    ExampleSecurityHotSpots

    Example of Architecture Hot Spots

    ExampleArchitectureFrame

    Scenarios Organized by Architecture Hot Spots

    ExampleArchitectureFrameTable

    Competitive Wins
    Our Blue Books have consistently been used for winning competitive assessments or at least making significant impact in key areas.  Whether there’s a gap in the tools or a gap in the platform, prescriptive guidance can smooth it out by creating a success path for customers.

    Example of beating IBM in Every Category Around Guidance

    ExampleCompetitiveResults  

    You can find a deeper rundown on the competitive assessments in my previous posts. 

    The Bottom Line on Blue Books
    The bottom line for me is that Blue Books have helped shape platforms and tools and to create glide-paths for customers through mental models, methodologies, and methods.  They’ve been a powerful way to share success patterns, help paint the bigger picture, and connect the dots across platform, tools, and guidance. 

    The adoption and usage has accelerated over the years to the point where just about any customer in the application development space that works with the Microsoft platform is familiar with either patterns & practices for the Microsoft Blue Books.

    Blue Books have been the freemium offering from Microsoft that have paved the way for premium experiences.

  • J.D. Meier's Blog

    Effectiveness Post Roundup

    • 11 Comments

    At Microsoft, I regularly mentor some fellow softies.   It can be tough to navigate the waters, find your strengths, figure out worklife balance, and deal with the stresses of the job, all while making things happen.  I help my mentees learn  the most effective ways for getting results in a tough, competitive environment.  It's challenging.  It's rewarding.  I've had several great mentors throughout my life at Microsoft, so mentoring is a way that I give back, sharing my lessons learned and helping others grow.  While my 1:1 sessions are the most effective, I try to share key practices more broadly in posts.  Here's a roundup of my various posts for improving effectiveness at work and life.  I organized them by meaningful buckets and provided an A-Z list at the end.  Enjoy.

    Career
    Learn how to find your path and get more from your career.  Work with the right people on the right things making the right impact.  These posts focus on career and worklife balance:

    Communication
    Communication is among the most important skills for getting results in work and life.  Empathic listening is the most important communication skills.  Improve the quality of your communication, and improve the quality of your life.  These posts focus on communication skills:

    Email
    Don't be a slave to your mail.  With the right approach, you can spend less time in your inbox and enjoy an empty inbox on a regular basis.  These posts focus on email management:

    Intellectual Horsepower
    Thinking is asking and answering questions.  Learn ways to improve your thinking through question-driven techniques and changing perspectives:

    Leadership
    Leadership is influence.  Amplify your results by improving your sphere of influence.  Leadership starts with self-leadership.  These posts focus on leadership skills: 

    Learning
    Learning is a life-long process.  Adopt practices that help you grow.  These posts focus on improving your learning:

    Motivation
    Motivation is your energy or desire to make something happen.  It's also the energy or desire for others to make something happen.  Learn how to improve your own passion for results as well as how to influence and motivate those around you.  These posts focus on motivation:

    Personal Development
    Personal excellence is a path, not a destination.  In life you're either climbing or sliding.  One key is to find ways to climb faster than you slide.  Another key is balancing your multiple demands and growing in your mind, body, career, emotions, financial, relationships and fun.  These posts focus on personal development: 

    Personal Productivity
    Make stuff happen.  Drive or be driven.  With the right approaches, you can carve out time for what's important and prioritize more effectively.  This is the key to getting results.  These posts focus on personal productivity:

    Project Management
    If you need to get something done, make it a project.   Whether it's a small-scale, personal project or a large, team-based project, there's patterns and practices you can use to be more successful.  These posts focus on project management:

    Teamwork
    Effective teamwork is a key skill in today's workplace.  Learn how to get more done with your colleagues.  These posts focus on improving your teamwork:

    Time Management
    You can't add more hours to the day, but you can spend your time more effectively.  You can also add more power hours to your day.  These posts focus on time management:

    Questions
    Questions are a powerful way to shape your thinking and mindset.  Ask better questions and get better answers.  These posts focus on asking and answering better questions:

    A-Z
    Here's the posts organized in a flat A - Z list for easy scanning:

    Sources of Insight
    If that's not enough for you, check out my project blog: Sources of Insight.  Sources of Insight is a browsable KB of insights and actions for work and life.  It's where I share my lessons learned from books, heroes and quotes.  You can read more about the mission and vision in the About page.

  • 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

    10 Success Patterns for PMs

    • 7 Comments

    Here's a brief set of success patterns I've shared with a few colleagues.  These are the patterns I see that make a difference in getting results.

    10 Success Patterns

    1. Empathic listening.
    2. Rapport before influence
    3. Character trumps emotion trumps logic
    4. Match their style
    5. Ask WIIFY
    6. Distinguish between responsibility and authority
    7. Turn chickens into pigs
    8. Adapt, adjust, or avoid situations
    9. Know the system.
    10. Analyze it over time.

    Success Patterns Explained
    Here's the essence of each:

    • Empathic listening.  Listen until the other person "feels" they've been heard.  Once they feel heard, they're more likely to listen to you.  You can do this 1:1 or in a large meeting.  Covey uses an "Indian Talking Stick."  The person with the stick talks until they feel heard.  A former Softie told me his team used an eraser as "the mutex."   See Stephen Covey Speaks at Microsoft.
    • Rapport before influence.  This is true whether it’s a presentation, interview … etc.. For example, go to a comedy club and see how the comedian gets the crowd laughing only  after they have rapport.  See How Might That Be True?
    • Character trumps emotion trumps logic.  If you base all your arguments on logic, but fail to persuade, now you know.  See Win the Heart, the Mind Follows.
    • Match their style.  You don't have to go overboard, but a little bridge can go along way.  If somebody is visual, could you whiteboard it for them?  If somebody's detail oriented, can you provide the details?  If somebody needs to hear action, can you turn your ideas into action?
    • Ask WIIFY.  Ask the question What's In It For You?  If you're a marketer, this might come natural for you.  If you're an engineer, this might feel weird.  It's about shifting the focus from the thing to the person. If nobody shows up to your meetings, tailor the invite to be explicit about what's in it for the attendees.
    • Distinguish between responsibility and authority.  Know whether you influence a decision or own it.  When you don't have authority, but you need to get results, leverage the model in Influencing Without Authority.
    • Turn chickens into pigs.  A pig's committed while a chicken's involved.  Don't let a chicken have a controlling vote, without turning them into a pig.  See Turning Chickens into Pigs.
    • Adapt, adjust, or avoid situations.  Learn how to read situations. Some situations you should just avoid.  Some situations you should adapt yourself, as long as you play to your strengths.  Some situations you should adjust the situation to set yourself up for success.
    • Know the system.   Analyze the problem from a system standpoint.  What are the components and subsystems?  What are the inputs and outputs?  Who are the players?   What levers can you pull that make the most impact?  If you don't know, who does?
    • Analyze it over time.  Look at the problem or solution over time. Build your temporal skills.  The more you play "what ifs" in the future, the easier it gets to anticipate.

    Do you have any favorite success patterns to share?

    My Related Posts

  • J.D. Meier's Blog

    How To Use ASP.NET Forms Auth with Azure Tables

    • 2 Comments

    While ramping up for Windows Azure, we're getting our feet wet with some basic application scenarios.   This is a quick step through of wiring up ASP.NET Forms Authentication to use Azure Table Storage for the user store.

    It’s longer than I like but I wanted to err on the side of being explicit.  It’s nice to know that when you’re going down a path that somebody else has been there and done that and you’re not on your own.  While your path may vary, at least you know this is one path that at least a few of our team members went down while creating repros for Azure authentication scenarios with ASP.NET.

    Stepping back, the big thing to know is that we didn’t find a Table Storage Membership provider for ASP.NET out of the box, but we found one in the additional C# samples.  You’ll see this in step 7.  Now, let’s start paving some paths …

    Summary of Steps
    Here are the steps at a glance:

    • Step 1.  Create a New Cloud Service Project.
    • Step 2.  Add References to AspProvider Project for the Azure Table Storage Provider
    • Step 3.  Add a Login Page
    • Step 4.  Create a Way for New Users to Register
    • Step 5.  Configure ASP.NET to use Forms Authentication
    • Step 6.  Configure ASP.NET to Restrict Anonymous Users
    • Step 7.  Configure ASP.NET to Use the Azure Table Storage Provider
    • Step 8.  Configure the ASP.NET Membership Provider
    • Step 9.  Add Test Code to Page_Load to Show the Forms Authentication Details
    • Step 10. Test Registering a New User and Logging in to the Application

    Here we go …

    Step 1. Create a New Cloud Service Project.
    In this step, you create a new cloud service project in Visual Studio:

    1. Start Visual Studio, from the menu select  “File” then click “New’ and then click ‘Project”
    2. In the “New Project’ dialog box, expand ‘Visual C#’ (or Visual Basic, if you are using it) in the ‘Project Types’ section, and select “Cloud Service”.
    3. In the ‘Templates’ section choose “Windows Azure Cloud Service” template, set the location, Name it as FormsAuthSample and click the “Ok” button.
    4. In the “New Cloud Service Project” dialog box, select “ASP.NET Web Role”, and click the “>” button to add it to the solution.  Then click the “Ok” button.  This will create a sample cloud Web Application, which is ready to be hosted in the cloud with all required configuration files etc.
    5. Run and verify that it works fine.

    Step 2. Add a Reference to the AspProvider Project for the Azure Table Storage Provider 
    We didn’t see a Table Storage Membership provider for ASP.NET out of box, but there are samples available for download:

    1. Unzip the WindowsAzure-AdditionalSamples.zip to some know location.  You can find the Windows Azure Additional Samples on this page.  (Note - if you followed my previous post, Getting Started with Windows Azure you should already have these samples.)
    2. Right click on the ‘FormsAuthSample” solution and choose Add -> Existing Project
    3. Browse to the location where you have extracted the samples, and select ASPProviders.proj from \\Samples\AspProviders\Lib folder. This will add the ASPProviders project to your solution.
    4. Add the reference to this project to your solution.  To do this, expand the WebRole1 node in the solution explorer, and right-click on References.
    5. Select Add Reference
    6. Select the Projects tab
    7. Select AspProviders, and click “Ok”

    Step 3. Add a Login Page.
    Use Solution Explorer to add a new Web form named Login.aspx to the WebRole1 site.

    Step 4.  Create a Way for New Users to Register
    Add the following two lines into the Login.aspx <form> tag

        <asp:Login runat="server" />
        <asp:CreateUserWizard runat="server"></asp:CreateUserWizard>

    It should resemble the following:

        <form id="form1" runat="server">
        <div>
        <asp:Login runat="server" />
        <asp:CreateUserWizard runat="server"></asp:CreateUserWizard>
        </div>
        </form>

    Step 5. Configure ASP.NET to use Forms Authentication
    In Web.config, add the following line insde the <system.web> tag:
            <authentication mode="Forms" />

    Step 6. Configure ASP.NET to restrict Anonymous Users
    In Web.config, add the following line inside the <system.web> tag:

          <authorization>
            <deny users="?" />
            <allow users="*" />
          </authorization>

    Note – The preceding configuration allows only authenticated users to access the application. The "?" indicates unauthenticated users and the "*" indicates all users. By denying unauthenticated users, any requests made by unauthenticated users are redirected to the login page. The loginUrl attribute of the <forms> element determines the name of the login page. The default setting of this attribute is Login.aspx.

    Step 7. Configure ASP.NET to Use the Azure Table Storage Provider
    In this step, you configure the Web application to use the AspProviders.TableStorageMembershipProvider.

    In Web.config, add the following lines inside the <system.web> tag:

          <membership defaultProvider="TableStorageMembershipProvider" userIsOnlineTimeWindow = "20">
            <providers>
              <clear/>

              <add name="TableStorageMembershipProvider" type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageMembershipProvider"
              applicationName="AspProvidersDemo"
        />

    </providers>
        </membership>

    Step 8. Configure the ASP.NET Membership Provider
    In Web.config, add the following code to the <appSettings> tag as follows:

      <appSettings>
        <!-- account configuration -->
        <add key = "TableStorageEndpoint" value="http://127.0.0.1:10002/devstoreaccount1"/>
        <add key = "AccountName" value="devstoreaccount1"/>
        <add key = "AccountSharedKey" value="Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw=="/>
      </appSettings>

    Note that we don’t have a lot of details on the AccountSharedKey, but we saw Jim Nakashima uses this value, so it’s good enough for now, until we know more.

    Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details

    1. Add a using statement to Default.aspx.cs in your WebRole1 project to add a reference to  System.Web.Security.
    2. Add the following code to Page Load of Default.aspx.cs in WebRole1:

    protected void Page_Load(object sender, EventArgs e)
    {
      Response.Write("Hello, " + Server.HtmlEncode(User.Identity.Name));

      FormsIdentity id = (FormsIdentity)User.Identity;
      FormsAuthenticationTicket ticket = id.Ticket;

      // optional - but if you use this add a reference to System.Web.Security
      Response.Write("<p/>TicketName: " + ticket.Name );
      Response.Write("<br/>Cookie Path: " + ticket.CookiePath);
      Response.Write("<br/>Ticket Expiration: " + 
                      ticket.Expiration.ToString());
      Response.Write("<br/>Expired: " + ticket.Expired.ToString());
      Response.Write("<br/>Persistent: " + ticket.IsPersistent.ToString());
      Response.Write("<br/>IssueDate: " + ticket.IssueDate.ToString());
      Response.Write("<br/>UserData: " + ticket.UserData);
      Response.Write("<br/>Version: " + ticket.Version.ToString());
    }

    Step 10. test registering a new user and logging in to the application

    1. Run the project by using the F5 key (this runs the project in Debug mode.) 
    2. Create a new user.  On your first visit, you need to create a new user (e.g. “bob”.)  Note that the password rules by default are alphanumeric plus one non-alphanumeric (for example, "password!") 
    3. Login to the application.  Sign in with your new username and password pair.

    The Web application should return something along the following lines:

    Hello, bob
    TicketName: bob
    Cookie Path: /
    Ticket Expiration: 3/17/2010 3:04:40 PM
    Expired: False
    Persistent: False
    IssueDate: 3/17/2010 2:34:40 PM
    UserData:
    Version: 2

    Share your feedback or results in the comments.  We’re path paving along with you.

    My Related Posts

  • J.D. Meier's Blog

    New Release: patterns & practices Performance Testing Guidance for Web Applications

    • 14 Comments

    We released the final version of our patterns & practices Performance Testing Guidance for Web Applications.  This guide provides an end-to-end approach for implementing performance testing. Whether you're new to performance testing or looking for ways to improve your current performance-testing approach, you will gain insights that you can tailor to your specific scenarios.  The main purpose of the guide is to be a relatively stable backdrop to capture, consolidate and share a methodology for performance testing.  Even though the topics addressed apply to other types of applications, we focused on explaining from a Web application perspective to maintain consistency and to be relevant to the majority of our anticipated readers.

    Key Changes Since Beta 1

    • Added forewords by Alberto Savoia and Rico Mariani.
    • Integrated more feedback and insights from customer reviews (particularly chapters 1-4, 9, 14, 18)
    • Integrated learnings from our Engineering Excellence team.
    • Refactored and revamped the performance testing types.
    • Revamped and improved the test execution chapter.
    • Revamped and improved the reporting chapter.
    • Revamped the stress testing chapter.
    • Released the guide in HTML pages on our CodePlex Wiki.

    Highlights

    • Learn the core activities of performance testing.
    • Learn the values and benefits associated with each type of performance testing.
    • Learn how to map performance testing to agile
    • Learn how to map performance testing to CMMI
    • Learn how to identify and capture performance requirements and testing objectives based on the perspectives of system users, business owners of the system, and the project team, in addition to compliance expectations and technological considerations.
    • Learn how to apply principles of effective reporting to performance test data.
    • Learn how to construct realistic workload models for Web applications based on expectations, documentation, observation, log files, and other data available prior to the release of the application to production.

    Why We Wrote the Guide

    • To consolidate real-world lessons learned around performance testing.
    • To present a roadmap for end-to-end performance testing.
    • To narrow the gap between state of the art and state of the practice.

    Scope

    • Managing and conducting performance testing in both dynamic (e.g., Agile) and structured (e.g., CMMI) environments.
    • Performance testing, including load testing, stress testing, and other types of performance related testing.
    • Core activities of performance testing: identifying objectives, designing tests, executing tests, analyzing results, and reporting.

    Features of the Guide

    • Approach for performance testing.  The guide provides an approach that organizes performance testing into logical units to help you incrementally adopt performance testing throughout your application life cycle.
    • Principles and practices.  These serve as the foundation for the guide and provide a stable basis for recommendations. They also reflect successful approaches used in the field.
    • Processes and methodologies.  These provide steps for managing and conducting performance testing. For simplification and tangible results, they are broken down into activities with inputs, outputs, and steps. You can use the steps as a baseline or to help you evolve your own process.
    • Life cycle approach.  The guide provides end-to-end guidance on managing performance testing throughout your application life cycle, to reduce risk and lower total cost of ownership (TCO).
    • Modular.  Each chapter within the guide is designed to be read independently. You do not need to read the guide from beginning to end to benefit from it. Use the parts you need.
    • Holistic.  The guide is designed with the end in mind. If you do read the guide from beginning to end, it is organized to fit together in a comprehensive way. The guide, in its entirety, is better than the sum of its parts.
    • Subject matter expertise.  The guide exposes insight from various experts throughout Microsoft and from customers in the field.

    Parts

    • 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

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

    Our Team

    Contributors and Reviewers

    • External Contributors and Reviewers: Alberto Savoia; Ben Simo; Cem Kaner; Chris Loosley; Corey Goldberg; Dawn Haynes; Derek Mead; Karen N. Johnson; Mike Bonar; Pradeep Soundararajan; Richard Leeke; Roland Stens; Ross Collard; Steven Woody
    • Microsoft Contributors / Reviewers: Alan Ridlehoover; Clint Huffman; Edmund Wong; Ken Perilman; Larry Brader; Mark Tomlinson; Paul Williams; Pete Coupland; Rico Mariani

    My Related Posts

  • J.D. Meier's Blog

    10 Things Great Managers Do

    • 3 Comments

    What do great managers do?   To put it simply, they bring out your best.   Whether it’s fire you up or get on your path or help you overcome your personal challenges, they help you flourish.

    Aside from all the managers I’ve had before Microsoft, I’ve had 14 managers at Microsoft.  I also regularly mentor people from different teams, so I get exposed to a lot of different management styles and patterns.   If I take a look from the balcony, what ten things do the best of the best managers do?    Here’s the list …

    1. Know the priorities.   The best managers know what’s important.   They make priorities clear and trade-offs make sense.   They help you and the team know what counts.   They focus on the vital few.   When the priorities are clear, a lot of things fall into place, and the work becomes meaningful.    The opposite is when everything is a priority.   The worst is when the priorities aren’t clear.   Without clear priorities, you don’t know what to optimize for or what success looks like.   You don’t even know whether you are even on track.  It leads to confusion, churn, and waste.     
    2. Focus on goals.   Focusing on the goals sets the stage for collaboration, focus, and priorities.   When the team knows the goals, it’s easier to know what success looks like.  It’s also easier to stay motivated.   It’s also easier to focus on the bigger picture and see the forest for the trees.   The opposite is “The How Trap.”   The How Trap is when a manager focuses on how people do their jobs.   Whether you call it micro-management, or too many cooks in the kitchen, or “my hands are tied”, it gets in the way of people playing their best game.   The best managers pair with you on setting the goals and give you the room to do what you do best.
    3. Know the capacity.   The best managers know the capacity.   They don’t overload you or the team beyond capacity.   They plan and design for smart work, rather than heroic efforts.   If all the work is dependent on long hours and going above and beyond, then it’s a risk to the business.   It’s not smart or effective execution.     
    4. Focus on learning and growth.    The best managers are great coaches.   They coach for growth.   They know when to provide direction, and when to back off.   They provide actionable feedback.   They don’t make things permanent, personal, or pervasive.   They focus on the challenges or the goals and they provide specific and actionable recommendations to bring out your best.   Call it “tough love”, but the best of the best managers here, tackle the tough stuff.   They do it with your best intentions.   They do it in a way that makes it safe to be vulnerable.   They use a language that’s empowering.   When something goes wrong, it’s not about blame, it’s what’s the learning and how to move forward.   The opposite is a critic that is only good at finding the flaws.
    5. Acknowledge the wins.   The best managers acknowledge the wins.   They catch you doing something right.   The best managers are aware of the tough stuff and the key challenges.   They know when you make progress, jump a hurdle, or scale a wall.   The opposite is a manager that only pays attention when something is wrong.
    6. Champion the work.   The best managers evangelize the work.   They are your champ.   They tell and sell your work so that it’s recognized and rewarded.   They amplify the impact by spreading the word.   They get the charter and defend the work so you don’t have to.   The opposite is when your work lacks any meaningful visibility or acknowledgement.
    7. Build vulnerability-based trust.      The best managers make it safe to fail.   It’s OK to bring your problems and challenges to them, and get open and honest feedback, without it being thrown back in your face.   It’s OK to go out on a limb, as part of driving for stretch goals and learning the ropes, and growing your skills.   In a nutshell, the best managers have your back.   The opposite is when a manager is waiting for you to step out of line or do something wrong.  Anything you share with them gets used against you.   Rather than go out on a limb or go the extra mile, you spend more energy defending or protecting yourself.
    8. Focus on strengths.   The best managers have you spend more time in your strengths.   They find the work that challenges you and grows your strengths.   The opposite is a manager that has you spend more time in your weaknesses or doing things outside your passions or strengths.    The secret that great managers know is that when people do what they love and they do what they’re great at, they do great work.   And it’s doing more great work that creates an arena of high-performance teams.  
    9. Lead with principles.   Rather than have a bunch of rules, great managers have a set of principles that establish the working environment.   The beauty of establishing principles is that people are empowered, but are governed with principles.   The principles help find the way forward within boundaries, while embracing and enforcing the values.   The opposite is chaos where there are no rules, or the other extreme where there is a rule for every little thing, and sometimes the rules aren’t shared.   A principle-driven leader helps create a work context where people are empowered and share a set of operating principles to guide and shape the way forward.
    10. Inspire action.   Great managers don’t use a bunch of carrots and sticks.   They inspire action.   There is a lot to say here.   Sometimes this means having a compelling vision that you connect with and want to be a part of.    Great managers know what fires you up and how to connect the work you do, with your unique talents and passions.   The best managers help you connect the work to your values.     The best managers help you internalize the rewards so that you are driving from your values and your passions and your strengths.     The best managers fan your flames by helping your see meaningful progress and they make the journey as rewarding as the destination.   They find a way to make the work something you would do for free.   The opposite is a manager who drives from fear, uses threats, or relies on extrinsic rewards and penalties.

    Now it’s your turn … In your experience, what are the best principles, patterns, and practices that great managers do?

  • J.D. Meier's Blog

    The Secret of Time Management

    • 14 Comments

    The secret to time management isn't more time management hacks at all.  Here's the keys I've found:

    • Manage energy not time.
    • Make room for your big rocks.
    • Use anticipation to drive versus react.

    I often here the argument, "if I had more time for this or that, I could ..."  Well, unfortunately, having more time doesn't always mean getting more done.  It doesn't guarantee getting the right things done either.  Sometimes I get more done in an hour than I can sometimes get done in a week.  Why is that?  For me, it's actually about energy.  There's only so many hours in a day.  While I can't make more hours in a day, I can use my energy better.  Sure there's lots of interesting little time savers, but there's plenty of time wasters too.  I find the force that makes the most measurable difference is the energy and engagement I bring to the table.

    Assuming I have all my energy ready to tackle my day, I need to distinguish between urgent and important.  If I'm only reacting to urgent, then I'm missing out on opportunity to deal with important, whether that's job impact or personal growth.  The moral of the story is, if I don't make time for the big rocks, the fillers in my day won't leave room.  I like Steven Covey's perspective on urgent vs. important in his First Thing's First book.  Here's a nice summary of the popular Make Room for the Big Rocks story.

    Anticipation is a actually a skill that I haven't worked on as much as I should.  I actually plan to do a 30 Day Improvement Sprint, when the time is right.  It's funny how many recurring things happen each year, that take me by surprise.  Birthdays.  Holidays.  Reviews.  Events.  Geeze!  You'd think I'd see the patterns ;)

    Well, I do.  I've seen the pattern of me reacting to events I don't anticipate.  While the corporate ninja expects the unexpected, I also find that with a little anticipation, a stitch in time saves nine.  If I make project plans, and there's a major event I didn't account for, I shouldn't be surprised when suddenly nobody's around.  At the same time, I'm sure I can find a way to leverage the sudden spurt of energy some folks have right after mid-year discussion.

  • J.D. Meier's Blog

    Six Steps for Enterprise Architecture as Strategy

    • 0 Comments

    One of my new favorite books is, Enterprise Architecture as Strategy, by Jeanee W. Ross, Peter Weill, and David C. Robertson.  My colleague, Danny Cohen recommended it as one of the best books on enterprise strategy and I agree.

    A big focus of the book is on execution and how to build a strong foundation for execution.  The key is an effective enterprise architecture.  With an effective enterprise architecture, you can improve business agility, achieve higher profitability, reduce time to market, lower IT costs, improve access to shared customer data, lower the risk of mission-critical systems failures.  Enterprise architecture as strategy means your enterprise architecture is addressing two key challenges: 1) integration and 2) standardization across the company.

    Six Steps to Build a Foundation for Execution
    Here are six steps Ross, Weill, and Robertson identify for re-thinking a foundation for execution and creating and effective enterprise architecture:

    • Step 1 –Analyze your existing foundation for execution.
    • Step 2 – Define your operating model.
    • Step 3 – Design your enterprise architecture.
    • Step 4 – Set priorities.
    • Step 5 – Design and implement an IT engagement model.
    • Step 6 – Exploit your foundation for execution for growth.

    Summary Table and Notes
    In this table, I  summarized key notes along with each step:

    Step Notes
    Step 1 - Analyze your existing foundation for execution
    • Identify digitized processes.
    • Figure out which processes are mission critical transactions.
    • Identify elements of IT that are world-class.
    • Evaluate the reach, security, data access, and flexibility you need.
    • Identify the strengths and weaknesses in your foundation.
    Step 2 - Define your operating model
    • Identify the processes that differentiate you competitively
    • Envision your ideal customer experience.
    • Determine how you want to grow (acquire or grow related businesses, expand globally, acquire competitors, offer more products and services.)
    Step 3 - Design your enterprise architecture.
    • Map out the essence of your business – your foundation for execution (companywide business processes, shared data, key technologies, and critical customer interfaces.)
    Step 4 - Set priorities.
    • Highlight priorities on the core architecture diagram (the base that the future capabilities depend on)
    • Align the project portfolio to match the enterprise architecture
    Step 5 - Design and implement an IT engagement model.
    • Create a formal IT engagement model (1) IT governance at senior levels, 2) disciplined project management across all major projects, 3) linkages that ensure IT governance and project management reinforce each other.
    Step 6- Exploit your foundation for execution for growth.
    • Plan to cash in on the benefits.
    • Allocate generous funding for training and development.
    • Align incentives so people are motivated to exploit the foundation.
    • Encourage and reward creativity.
  • J.D. Meier's Blog

    A Language for Architecture

    • 5 Comments

    ALanguageForArchitecture

    My Architecture Journal article is live, A Language for Architecture.   I wrote the article to share the map of application architecture we created during our patterns & practices Application Architecture Guide 2.0 project.  It's a simple language for helping you get in the ballpark when you're traversing the very large space of software architecture.   By framing and naming the space, we can more effectively share our principles, patterns, and practices for application architecture.   This also helps consolidate all the great information spread over time and space and threads and heads.   More importantly, if we simplify how we talk about architecture, we can move up the stack as well as pave paths for others and help mentor others in our field.  Instead of asking basic questions like what is architecture, we can ask things like how do we define archetypes for the cloud or how do improve product line engineering for common systems and application types? In our case, we're using the language to help rationalize our portfolio of assets in our patterns & practices product line.

    Why the Map
    There's an explosion of concepts in the architecture space.  While working on the Application Architecture 2.0 Guide, we needed a simple, but effective bird's-eye view of the space.  By framing and naming the space, we created a shared vocabulary, helped avoid information overload, and made it easier to find, organize, and share principles, patterns, and practices with customers, field, and product teams.  It's good for the ecosystem.

    Usage Scenarios
    Here's some usage scenarios:

    • Heat Map.  If you do product planning or competitive analysis you can use the map and language to create heat maps and create a "consumer reports" for the space you are in.  You can identify key hot spots and quickly drill in or evaluate the level of maturity in that domain.  You can use the map to find the most important areas to invest.  That's key, especially in today's economic landscape.
    • Hot Spots.   By mapping out hot spots you build a catalog of your key engineering decisions.  These become your focus points.  By focusing efforts you improve your results.  For example, if cloud computing is a hot spot, you might identify manageability within that and then you might invest your energy in reducing friction or creating opportunity in that hot spot.
    • Solution Engineering.   If you build applications you can use the map and language for quickly traversing key engineering decisions.  You can use it to quickly identify your key risks as well as explore potential solution options.  It helps you identify what you know, don't know and need to know next.  It also helps you quickly rip through technology decisions.
    • Architectural Exploration.   You can use the map as a way to explore existing systems.  By chunking up architectures into things like archetypes, qualities, hot spots ... etc. you can drill into them more effectively.  For example, you might go on an architectural expedition to build a catalog of common application patterns for your group.
    • Whiteboarding.   Effective whiteboarding is an art.  That said, whiteboarding is one of the most important tools in our industry when it comes to sharing knowledge and getting people on the same page.   You can use the language, maps, and frames to improve your whiteboarding skills by using common elements from the map.
    • Product-line engineering.  If you build software, you can use the map to get more precision over your product line by defining the scenarios, the requirements, the archetypes and hot spots.  You can also use these to differentiate.
    • Slideware.  If you have to build slides, you can use the map, the language, and the visuals to more effectively share what's important.
    • Prescriptive Guidance.   If you're in the decision improvement business, then using a common map and frames will help you organize and share patterns and practices more effectively.  What if we could easily traverse the common data access patterns for RIA applications from a security, performance or manageability perspective?  We get closer to the capability when we share common maps.

    Key Concepts
    Here's some key concepts behind the map and language:

    • Hot Spot driven.  Rather than exhaustive, the maps, language, and frames are hot spot driven.  If you can see the forest from the trees, you have a better vantage point and can more selectively drill down or elaborate as needed.   Hot spots are also where the action is.  See Security Hot Spots and Performance Hot Spots.
    • Expandable by design.  The maps are expandable by design.   You can unfold, elaborate or expand each area as needed.   You can tailor it for your context.  The maps gives you a baseline of hot spots to start from so you don't have to start from scratch.
    • Overlays.   The maps, language, and frames are backdrops.  This means we can overlay principles, patterns, and practices.  This also means we can overlay products or technologies or solution assets, such as reusable code.
    • Whiteboard oriented.    The maps, language and frames are oriented towards whiteboard usage, simply because it's one of the most universal tools in our field.  By optimizing around whiteboard usage and humans over tools, we reduce friction around sharing basic information.
    • Plays well with others.   No matter what your favorite framework or mental models are, you can leverage the maps, language and frames.  We didn't set out to build an exclusive set.  Instead, we set out to map out an inclusive set of concepts that can easily stretch to fit.  It's platform agnostic and if anything, it's most tightly bound to the knowledge areas of software architecture.  In the words of Bruce Lee, "absorb what is useful."
    • Real-world over academic.   We chose to optimize around the language, maps, and frames we see in practice.  We needed it to be simple to explain whether we're in a team full of developers or a doing a presentation for business decision makers.  It's a simple way to look at the legos and  organize them in a meaningful way.

    The Map
    The key components of the language include:

    • User, Business, and System Perspective.   Architecture is a constant balance of user, business, and technical concerns.  For example, the user wants a response time of x, but the cost and impact on the system side have to make business sense.  When you group by user, business, and system stories you get more precision around the drivers and goals and you can include the right people for the right decisions, as well as keep checks and balances.  See What are the User, Business, and System Goals.
    • Architecture Frame.  This is the main map that includes the context, the app types, the architectural styles, and the application feature frame.  The context is expressed with scenarios, requirements / constraints, and quality attributes.
    • Application Archetypes (App Types).  Application Types are simply blueprints for classes of applications.  In our Application Architecture Guide 2.0, we called out mobile, RIA, Web, Rich Client, and Services.  Those are technical types.  You could also call out a set of business types. or a set of core system archetypes.  The key is to identify a set of types for your business so you can think in terms of a product-line.  See Application Types.
    • Quality Attributes.   This includes system, run-time, design, and user qualities.  For example, a run-time quality would be availability, while a design quality would be conceptual integrity.  See Quality Attribute List.
    • Scenarios.  You can't design or evaluate an architecture in a vacuum.  Scenarios give you the context.  The scenarios are a really important element.  In terms of architecture, the architecturally significant use cases are vital to making the right trade-offs.  You can find architecturally significant scenarios by looking at the intersections of quality attributes or hot spots with application features.  See App Types, Verticals, and Scenarios and What's a Scenario?.
    • Architectural Styles.  Architectural styles are simply sets of principles that shape the software.  We grouped styles by  big decision areas: communication, deployment, domain, interaction and structure.The beauty of architectural styles is we can talk about higher-level goals before getting into specific technologies.  For example, if you choose SOA as your architectural style for your communication, you can then evaluate whether WCF or ASMX helps you implement those principles.  Every app is a mash up of styles. 
    • Requirements and Constraints.   Requirements and constraints are simply what's required of the system.  Again, this is where user, business, and system perspectives matter.  We called out functional, non-functional, technological, and constraints.  Non-functional would include quality attributes and constraints would include organizational and industry compliance.  See Requirements Types and  User Requirements vs. System Requirements.
    • Application Feature Frame.   This is a set of hot spots focused on a common set of key engineering decisions.  We called out Caching, Communication, Concurrency and Transactions, Configuration Management, Coupling and Cohesion
      Data Access, Exception Management, Layering, Logging and Instrumentation, State Management, Structure, Validation, and Workflow.  These are  the types of decisions you don't want to make up on the fly and you want to avoid do-overs.  You'll also notice our industry is rich with principles, patterns, and practices in these categories, as well as reusable components.  For example, you can overlay Enterprise Library on several of these areas.   See Application Infrastructure Frame.
    • Application Frames.   These are hot spots based on a given application type.  For example, for Web applications, we defined Authentication, Authorization, Caching, Exception Management, Logging and Instrumentation, Navigation, Page Layout (UI), Page Rendering, Presentation Entity, Request Processing, Service Interface, Session Management, Validation.  Notice that the map has a lot of similar categories to the core application infrastructure frame.  The key is context.  Now we are talking about validation within Web applications.  Also notice that some hot spots are more Web centric such as page layout and page navigation.  Also notice that we can overlay key Web patterns on these hot spots.  Instead of a laundry list of patterns, we can find, organize, and share key patterns for these hot spots.
    • Layers, Components, and Tiers.  We called out layers, components, and tiers so that we could have a common backdrop with the various existing bodies of work.   We kept layers logical and tiers physical (a precedent set back in 2001 to help untangle confusion.)  We called out the presentation, business, data, and service layers.  You can extend that for things like productivity layers or manageability layers.  Keep in mind that layers are fractal, in other words you might have a service that has a presentation, business, and data layer within it.  Effectively you can think in terms of macro and micro levels.  For components we called out presentation components (user interface, user process), business components (application facade, business, business entity, business workflows), data layer components (data access logic, data helpers/utilities, service agents), and service layer components (service interfaces, message types).  For tiers, we called out 2-tier, 3-tier, and N-tier.
    • Pattern Maps.  We created pattern maps based on the frames.  For example, for each application type (Web, RIA, Mobile ... etc.) we used the hot spots to overlay relevant patterns.  This helped us surface up the most important patterns for a given topic and avoid information overload.
    • Product and Technology Maps.   We created product and technology maps organized by scenarios, application types, and hot spots.  The key here was making it easy to traverse the problem space and overlay the solution space.
  • J.D. Meier's Blog

    How To Use the Six Thinking Hats

    • 4 Comments

    How do you get past deadlocks in a meeting?  You can apply the Six Thinking Hats.  I've blogged about the Six Thinking Hats before, but to summarize, it's a way to get everybody thinking about the problem in a collaborative way. 

    The Keys to The Six Thinking Hats
    The real key here is that rather than circular or deadlock debates, you focus the group on a particular viewpoint at a time.  This is a similar to writing, then editing vs. editing while your write, or brainstorming, then critiquing vs. critiquing while you brainstorm.  The big difference is that rather than just brainstorming and critiquing, you're looking at the issue from multiple, specific angles.  On the people side of this technique, you're letting people wear a different "hat", in a safe, constructive way.

    Applying the Six Thinking Hats 
    The approach below is lightweight and low-overhead, but gets you 80% there without requiring everybody to know the details of the Six Thinking Hats.

    Summary of Steps

    • Step 1.  List the questions that represent the hats
    • Step 2.  Walkthrough each question as a team
    • Step 3.  Modify the approach

    Step 1.  List the questions that represent the hats
    List a set of questions on the whiteboard to represent the hats.  You can do this either at the start of the meeting or when you hit a sticking spot.
    Here's the Six Thinking Hats:

    • White Hat - the facts and figures
    • Red Hat - the emotional view
    • Black Hat - the "devil's advocate"
    • Yellow Hat - the positive side
    • Green Hat - the creative side
    • Blue Hat - the organizing view

    Here's an example set of questions you can use to represent the hats:

    • What are the facts and figures?
    • What's your gut reaction?  How do you feel about this?
    • Why can't we do this?  What prevents us?  What's the downside?
    • How can we do this?
    • What are additional opportunities?
    • How should we think about this? (what are the metaphors or mental models)

    The sequence of the questions can matter.  For example, it wouldn't make sense to start thinking up solutions before you've focused on the problem.

    Step 2.  Walkthrough each question as a team
    Walkthrough each question as a team.  This is the key.  Rather than debating each other, you're now collaborating.  You'll be surprised when suddenly your team's "Devil's Advocate" is now showing off their ability to dream up wild solutions that just might work!

    Step 3.  Modify the approach.
    If it's not working, change the approach.  For example, you might find that you started with the wrong "hat" or question.  See if switching to another question or hat makes a difference.  The key is to keep this lightweight but effective.

    This isn't a heavy handed approach.  Instead, it's a subtle shift in stratey from free-for all debate to focusing and coordinating your team's thinking power in a deliberate way.  This lets everybody get heard as well as really bang on a problem from multiple angles in a teamwork soft of way.

    More Information

  • J.D. Meier's Blog

    Improvement Frame

    • 3 Comments

    As a mentor at work, I like to checkpoint results.  While I can do area-specific coaching, I tend to take a more holistic approach.  For me, it's more rewarding to find ways to unleash somebody's full potential and improve their overall effectiveness at Microsoft.  Aside from checking against specific goals, I use the following frame to gauge progress.

    Improvement Frame

    Area Prompts
    Thinking / Feeling
  • Do you find your work rewarding?
  • Are you passionate about what you do?
  • Are you spending more time feeling good?
  • What thoughts dominate your mind now?
  • Is your general outlook more positive or negative?
  • Do you have more energy or less in general?
  • Are you still worried about the same things?
  • Are you excited about anything?
  • Have you changed your self-talk from inner-critic to coach?
  • Situation
  • Are you spending more time working on what you enjoy?
  • What would you rather be spending more time doing?
  • Do you have the manager you want?
  • Do you have the job you want?
  • Are you moving toward or away from your career goals?
  • If your situation was never going to change, what one skill would you need to make the most of it?
  • Time / Task Management
  • Are you driving your day or being driven?
  • Are you spending less time on administration?
  • Are you getting your "MUSTs" done?
  • Are you dropping the ball on anything important?
  • Do you have a task management system you trust?
  • Are you avoiding using your head as a collection point?
  • How are you avoiding biting off more than you can chew?
  • How are you delivering incremental value?
  • Domain Knowledge
  • Have you learned new skills?
  • Have you sharpened your key strengths?
  • Have you reduced your key liabilities?
  • What are you the go-to person for?
  • What could you learn that would make your more valuable to your team?
  • Strategies / Approaches
  • What are you approaching differently than the past?
  • How are you more resourceful?
  • How are you finding lessons in everything you do?
  • How are you learning from everybody that you can?
  • How are you improving your effectiveness?
  • How are you modeling the success of others?
  • How are you tailoring advice to make it work for you?
  • Relationships
  • Are you managing up effectively?
  • Are your priorities in sync with your manager's?
  • Has your support network grown or shrunk?
  • How are you participating in new circles of influence?
  • How are you spending more time with people that catalyze you?
  • How are you working more effectively with people that drain you?
  • How are you leveraging more mentors and area specific coaches?
  • I've found this frame very effective for quickly finding areas that need work or to find sticking points.  It's also very revealing in terms of how much dramatic change there can be.  While situations or circumstances may not change much, I find that changes in strategies and approaches can have a profound impact.  My take on this is that while you can't always control what's on your plate, you can control how you eat it.

  • J.D. Meier's Blog

    How To Enable SSL on Windows Azure

    • 2 Comments

    As part of our Azure Security Guidance project, we tested setting up SSL during our exploration.  To do so, we created a self-signed certificate and deployed it to Azure.  This is a snapshot of the rough steps we used:

    • Step 1 - Create and Install a test certificate
    • Step 2 - Create a Visual Studio project
    • Step 3 - Upload the certificate to Windows Azure Management portal
    • Step 4 - Publish the project to Windows Azure
    • Step 5 - Test the SSL

    Step 1 - Create and Install a test certificate

    • Open a Visual Studio command prompt
    • Change your active directory to the location where you wish to place your certificate files
    • Enter the following 2 commands

    makecert -r -pe -n "CN=AzureSSL" -sky 1 "azuressl.cer" -sv "azuressl.pvk" -ss My

    pvk2pfx -pvk "azuressl.pvk" -spc "azuressl.cer" -pfx "azuressl.pfx" -pi password1

    Note - You can find an explanation of the command line arguments for makecert.exe and pvk2pfx.exe on MSDN. 

    Step 2 - Create a Visual Studio project

    • File, New Project
    • Select "Cloud" from "Installed Templates" list on left
    • Type "AzureSSL" for name, and hit OK
    • Select Web Role from the list, and ">" to add to solution
    • Click OK
    • Right-click \Solution\AzureSSL\Roles\WebRole1, and select "Properties"
    • Select "Certificates" tab on left
    • Click "Add Certificate" button on top bar
    • Change "Store Location" drop-down to "CurrentUser"
    • Click "..." button under Thumbprint
    • Select AzureSSL cert from list and click OK
    • Select "Endpoints" tab on left
    • Enable the "HTTPS:" checkbox
    • Select "Certificate1" from the SSL certificate name drop-down

    Step 3 - Upload the certificate to Windows Azure Management portal

    • Open http://windows.azure.com
    • Select the Service you will deploy to, or create one if necessary
    • At the bottom of the management page, find the Certificates area, and click the "Manage" link on the right
    • Hit the "browse" button and select the PFX file created in step 1
    • Enter "passWord1" and confirm it in the password textboxes
    • Click "Upload"

    Step 4 - Publish the project to Windows Azure

    • In your Visual Studio project from step 2, right click \Solution\AzureSSL and select "Publish"
    • In the Windows Explorer window that pops up, copy the path to the directory displayed into the clipboard
    • Switch to your browser with the Windows Azure Management portal open
    • If you are still in the manage certificates screen, return to the service management screen
    • Click the "Deploy" button
    • Under "Application Package" area, select the "Browse" button
    • In file open dialog that pops up, paste the path from your clipboard to navigate to your VS package
    • Select the AzureSSL.cspkg, and click "Open"
    • Under the "Configuration Settings" area, select the "Browse" button
    • Select the ServiceConfiguration.cscfg file, and click "Open"
    • At the bottom of the Deploy screen, enter AzureSSL in the textbox
    • Click "Deploy"
    • When the deployment completes, click the "Run" button

    Step 5 - Test the SSL

    • Once the Web Role has completed initializing, click on the "Web Site URL" link
    • Change the URL scheme to HTTPS (in other words change http to https), and open the page

    Your results may vary here based on your browser, but you'll most likely see a warning about the certificate being for a different site, or not being from a trusted source. If you permit access to the site, the page will render empty and you browser should indicate that the page was delivered over SSL with a lock icon or something similar.

    My Related Posts

  • J.D. Meier's Blog

    WCF Code Samples Collection

    • 4 Comments

    image

    The Microsoft WCF Code Samples Collection is a roundup and map of WCF code samples from  various sources including the MSDN library, Code Gallery, CodePlex, and Microsoft Support.

    You can add to the WCF code examples collection by sharing in the comments or emailing me atFeedbackAndThoughts at live.com.

    Common Categories for WCF Code Samples
    The WCF Code Samples Collection is organized using the following categories:

    image

    WCF Code Samples Collection

    Categories

    Items

    Addresses

    AJAX / JSON

    Bindings

    Clients

    Cloud / Windows Azure

    Contracts

    Cryptography

    Discovery

    Exception Management

    Extensibility

    General

    Hosting

    Interoperability

    Performance and Scalability

    Queues and Reliable Sessions

    Security

    Session Management

    Transactions

    WCF Data Services

    WCF RIA Services

    WCF Syndication

    Web

    My Related Posts

  • J.D. Meier's Blog

    Agile Methodology in Microsoft patterns & practices

    • 0 Comments

    “I put my heart and my soul into my work, and have lost my mind in the process.” -- Vincent Van Gogh

    I find myself mentoring on Agile practices and Agile methodology on a regular basis.  More and more teams are needing to stay connected with customers, respond to change, and flow value along the way.   I find that if you know what Agile methodology looks like, it’s easier to get started.   In this post, I’ll share what an implementation of Agile methodology looks like.

    When I was on the Microsoft patterns & practices team, we used a combination of XP/Scrum for executing projects.  We called our agile methodology, "Customer-Connected Engineering"or CCE.  The following table is an overlay of customer-connected activities on top of the agile methodology:

    Phase Core Activities Customer-Connected Engineering Activities
    Exploration
    • Go / No Go
    • Business Case
    • Product Backlog
    • Release Planning
    • Team Role Assignments
    • Vision Scope
    • Broad Customer Surveys
    • Customer Advisory Board Setup
    • Stories / Scenarios
    • Prioritization
    Iteration 0
    • Clarification of process, responsibilities, and roles
    • Infrastructure setup
     
    Iteration N
    • Iteration Planning
    • Daily Stand-Up
    • Mid-Iteration Checkpoint
      Review
    • Retrospective
    • Internal Release (Optional)
    • Customer Release (Optional)
    • Stories / Scenarios
    • Prioritization
    • Demos
    • Product Drops
    • Feedback
    Stabilization
    • Remaining Work Completed
    • Outstanding Bugs Resolved
     
    Release
    • Documentation Updates
    • Incomplete Stories Removed
    • Final Test
    • Remaining Bugs Resolved
    • Release Bar Met
     

    The activities on the left-side of the table are core activities in patterns & practices projects.  If you’re familiar with XP/Scrum, you’ll be familiar with the activities.  On the right-hand side are customer-connected activities.

    10 Highlights of the Agile Methodology and Customer-Connected Engineering
    Here are some of the most important points and distinctions:

    1. 40 Hour Work Week.   In my experience, a 40 hour work week is a benchmark of the most effective teams.  They have work-life balance.  They have buffer to respond to opportunity and to deal with crunches.  They have processes in place, they invest in their learning and growth, and they move up the stack instead of always solving the basics.  Instead of perpetual fire-fighting, they are more deliberate about planning and strategy and they anticipate their customers and the market (through empathy and staying connected to customers.)  They learn and respond and can turn on a dime.  They have a dashboard, they know the score, and they can change their approach.   See 40 Hour Work Week at Microsoft.
    2. Exploration and Execution.   One of the best moves we did was introduce the idea of an “Exploration” phase.    This is where we would explore and test customer value, while also exploring technical risk.  By doing architectural spikes we could very quickly identify potential technical risks that would impact the project, long before we even started the project.  In general, our exploration phase was anywhere from 4 – 8 weeks.  It was also a practical way to drive innovation and explore new opportunities.  We reduced risk by setting a limit on time and budget.  This gave creative freedom within the box, but constrained risk and cost for the business, while exploring high potential opportunities.
    3. Demos.   Demos are the key to product success, if you do them early enough.  Demos actually serve two functions.  First, they force you to put together that you’ve got into a presentable form.  What looks good on paper, or sounds good in your mind, might not be that good when you actually present it.   So, the demo is a great forcing function for you to identify what’s actually valuable and how to package and showcase that value in a presentable way.    Second, the value of the demo is the actual feedback.  As a rule, I like to Demos on Thursdays each week, as a way to bring work together into a package.  It helps people show off their stuff and feel acknowledge and appreciated.  If it’s an internal demo, then it helps people on the team get real feedback from their peers before going more broadly.  If it’s a public demo, then it’s a great chance to get real feedback from actual users.  I’m a fan of failing fast and failing often.   You get better through failure than you do from success because you learn *why* and *how* to improve.   As Tony Robbins puts it, when you succeed you party and when you fail you ponder.  My guiding principle is to carry the good forward and to turn failure into feedback.
    4. Iterations.   Iterations are a wonderful thing.  They help you set a cadence for shipping stuff, doing demos, and executing your work.   In patterns & practices, the most common pattern was two-week iterations.  I originally used three-week iterations, and then moved to two-week iterations, and eventually moved to one-week iterations, for a variety of reasons.  The one-week iterations reduced my iteration planning time from one or two hours down to 30 minutes max.  It also helped people on the team feel more connected to their results and to drive a great week.   It also meant people had to spend less time estimating their work, and it meant that estimates were more accurate.  In simple terms, it meant that the team could plan a great week, and on Friday reflect on their results without bleeding things into the net week … bite off a weeks’ worth of work, and finish a week’s worth of work.   This radically improved our agility and our ability to execute in a more predictable and streamlined way.   This also set the stage for more lean practices, and on my projects, I was a fan of using a Kanban to visualize the work, reduce open work, and to improve our flow.  I also liked that Kanban is a very customer-connected approach to development in that it is “pull” vs. “push.”  It’s the ultimate in “demand-driven” development.
    5. Product Backlogs and Sprint Backlogs.   Your “Product” backlog is everything that needs to get built.  The “Sprint” backlog is simply the chunk you are biting off for this particular iteration.   This distinction is an important one.   It’s great to have one place to look for everything that makes up the possibilities, the pains, and the needs of your potential product.   It’s also great to be able to grab a meaningful chunk for execution.   The real trick with biting off a meaningful chunk is knowing the dependencies and being able to sequence in a way that flows value while reducing risk.  This is also another reason why user stories are helpful.  They are a collection of customer value at your finger tips.
    6. Prioritization.   To prioritize our user stories and backlog items, we’ve used surveys extensively.   A proven practice is to play a game of “spend a $100.” (See Enterprise Library 5.0 Product Backlog Prioritization Survey.)   An important point is that the prioritization surveys are input into your prioritization planning.  They help you balance perspective and identify actual demand.  In a best case example, they help you find the surprises or disconnects.  Customers usually know what they want, but they don’t always know what they need, and there is often an awareness issue.   If you’re familiar with marketing, this is specifically about finding, surfacing, and addressing latent needs.   Customers may want the “cheaper” bridge, but as the engineer, you need to make sure they know the trade-offs, and that a “safer” bridge might be a better bet.  What’s important is that you create an opportunity for customers to voice their priorities and that you keep an open mind to being surprised.
    7. Project cycles and product cycles.  Having a distinction between the project and product cycle help you optimize and use the right tool for the job.  For a simple example, Scrum is more of a project process, while XP is more of a product development process.  The project cycle is important at the business level.  It’s the cadence of the projects.  It’s where the vital few milestones are established in terms of start, key checks, ship, and post-mortem.  Product cycles on the other hand, are geared towards the product development.   The real key here is that if you have multiple teams, you can standardize on the project cycle, while you let each team choose it’s most effective product cycle or development methodology.  The product cycle would simply feed into the agreed milestones at the project cycle level to support the rhythm at the business level.
    8. Release Planning.    Release planning is a significant body of work.   One of the most important features of release planning in patterns & practices was determining the Minimum Credible Release (MCR.)  This was the minimum product we could ship that would actually be worth it.   To illustrate this to management, we simply drew a cut-line in terms of scenarios.
    9. Scenarios and Stories.   In many ways, scenarios and user stories are the backbone of the product.   They are one of the best ways to set scope.   Scenarios and stories are also a great way to capture and share requirements in a more contextual way.   You get customers to tell you their specific goals and tasks.   If you want to build a better product, then focus on building a great set of scenarios and stories.   These are the backbone of your product.   They set the tests for success.   They are your tool for prioritizing.   To stay customer connected, your customers directly contribute the stories and scenarios, and they help prioritize the stories and scenarios with you.   This is how you build empathy for the customer’s pains and needs.   For examples, see WCF Security Scenarios in Azure and WCF Scenarios Map.
    10. User, Business, and Technical Perspective.   Maintaining and balancing perspectives and points of view is key to successful product development.   You’ll find that a lot of conflict and arguments happen because everybody is “right”, but they are “right” only from their perspective, and you need to know which perspective they are arguing.  The perspectives that you will most often bump up against in product development are user, business, and technical.   If you keep those in mind, then whenever there is an argument or a conflict, then you can do a quick sanity check to figure out what perspective are they arguing from.   When you know this, it is a lot easier to build bridges too or speak the right language.   When speaking to the business, talk about value and cost, budget, and quality.  Or talk about cycle time and efficiency or effectiveness.   Or focus on the “What” or the “Why.”  When speaking to the technical, it’s fine to elaborate on trade-offs, the “How”, and implementation details.  Tech is a great perspective to elaborate on system concerns or quality attributes like security, performance, or reliability.  When talking tech, it’s a great perspective to speak about features and specifics.   When speaking to the customer perspective, here is where you want to talk about persona, roles, and goals.  Or it’s a great place to talk about pains and needs.   A great rule of thumb that has served me well is to speak in terms of “persona-based goals with scenarios.”  See Perspectives Frame and User Experience, Tech Feasibility, and Business Value.

    There is a lot more I could say, and a lot more I could share, and I will.   For example, I learned a lot from doing Retrospectives for various product teams around Microsoft.    I also learned a lot on building more effective business cases.   I’ve also learned a lot about doing effective daily standups with distributed teams around the world.  The most important thing though that I learned, at least in terms of helping teams get up and running with Agile, is how to show and share end-to-end life-cycles.   For example, I have a simple model now of the Project Cycle + Product Cycle and the workstreams below each, now in my head.  In a future post, I’ll share what that looks like, if there is interest.

    My Related Posts

  • J.D. Meier's Blog

    Sample Application for .NET 4.0 - Layered Architecture and DDD Patterns Sample Applications

    • 6 Comments

    A code sample is worth a thousand words.  Here are a few projects to take a look at that go beyond just code snippets to show you how to put key technologies together in the form of sample applications.  (Note, if you are looking for just code snippets and focused code samples, you can check out the Microsoft All-in-One Code Framework project site on CodePlex.)

    Layered Architecture Solution Guidance
    Project Site - http://layerguidance.codeplex.com

    ”Designing and creating layered applications can be a challenging task to developers. Layered Architecture Solution Guidance is a Microsoft Visual Studio 2010 extension that provides a set of tools and guidance aimed at simplifying the development of layered applications.
    Layered Architecture Solution Guidance is a
    Guidance Automation Extension that integrates with Microsoft Visual Studio 2010 to allow developers to easily create and organize their projects in a layered fashion following the structure that is illustrated in the Layered Architecture Sample for .NET. It provides a set of solution templates integrated with a suite of code generators to make developing layered applications much simpler and quicker.

    Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App
    Project Site - http://microsoftnlayerapp.codeplex.com/

    The main goal is to show how to use .NET 4.0 wave technologies implementing typical DDD patterns: N-Layered Architecture, Domain Entities, Aggregates, Repositories, Unit of Work, Domain Services, Application Services, DTOs, DTO-Adapters, etc.

    Improvements in the Domain Layer

    • Using EF 4.1 POCO Code-First approach for Domain Entities/Aggregates/ValueObjects
    • Added more Domain logic within entities (no anemic domain)
    • Better exposure of Aggregates’ elements
    • Better support to navigations between Aggregates and elimination of inverse relationships not needed
    • Entity Validation support
    • Specification pattern implementation, use of expressions as specifications and composition support

    Improvements in the Application Layer

    • DTO and DTO-Adapters support
    • Validation support
    • Improvements in exception management

    Improvements in the Data-Persistence-Infrastructure Layer

    • Using EF 4.1, CodeFirst, DbContext
    • Persistence layer simplification and improvements
    • IoC/Unity: Elimination of abstractions no needed
    • Better testing strategy for Integration Tests

    Improvements in the Presentation Layer

    • Reviewed and minor improvements in MVVM code.
    • In current V2.0 version we only support a Silverlight client. We'd like to add more clients in the future.

    Improvements in the Distributed-Services Layer

    • Segregation in 2 Web-Services (One per MODULE).
    • Improvements regarding WCF exceptions handling (less spread code in Catch)
    • We currently use SOAP Web-Services, but we will switch to REST in the coming future when the new WCF Web API (WebApi.all) (still in beta) will support Silverlight.
  • J.D. Meier's Blog

    Now on MSDN: patterns & practices Performance Testing Guidance for Web Applications

    • 9 Comments

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

    Contents at a Glance
    Here's the

    Chapters

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

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

  • J.D. Meier's Blog

    Project Management Body of Knowledge (PMBOK) Framework

    • 0 Comments

    Here is a quick map of the process groups, knowledge areas, and processes in the PMBOK (Project Management Body of Knowledge).  Regardless of the PMI certification, I think it’s useful to know how the knowledge for project management is organized by experts and professionals.   This will help you more effectively navigate the space, and learn project management at a faster pace, because you can better organize the information in your mind.

    If you are a program manager or a project manager, the categories are especially helpful for checking your knowledge and for thinking of projects more holistically.   You can also use the knowledge areas to grow your skills by exploring each area and building your catalog of principles, patterns, and practices.

    Process Groups and Knowledge Areas
    Here is a quick map of the process groups and knowledge areas in the Project Management Body of Knowledge:

    Category

    Items

    Process Groups

    1. Initiating
    2. Planning
    3. Executing
    4. Monitoring and Controlling
    5. Closing

    Knowledge Areas

    1. Project Integration Management
    2. Project Scope Management
    3. Project Time Management
    4. Project Cost Management
    5. Project Quality Management
    6. Project Human Resource Management
    7. Project Communications Management
    8. Project Risk Management
    9. Project Procurement Management

    Knowledge Areas and Processes
    Here is a quick topology view of the Knowledge Areas and the processes:

    Knowledge Area

    Processes

    Project Integration Management

    • Develop Project Charter
    • Develop Primary Project Scope Statement
    • Develop Project Management Plan
    • Direct and Manage Project Execution
    • Monitor and Control Project Work
    • Integrated Change Control
    • Close Project

    Project Scope Management

    • Scope Planning
    • Scope Definition
    • Create WBS
    • Scope Verification
    • Scope Control

    Project Time Management

    • Activity Definition
    • Activity Sequencing
    • Activity Resource Planning
    • Activity Duration Estimating
    • Schedule Development
    • Schedule Control

    Project Cost Management

    • Cost Estimating
    • Cost Budgeting
    • Cost Control

    Project Quality Management

    • Quality Planning
    • Perform Quality Assurance
    • Perform Quality Control

    Project Human Resource Management

    • Human Resource Planning
    • Acquire Project Team
    • Develop Project Team
    • Manage Project Team

    Project Communication Management

    • Communication Planning
    • Information Distribution
    • Performance Reporting
    • Manage Stakeholders

    Project Risk Management

    • Risk Management Planning
    • Risk Identification
    • Qualitative Risk Analysis
    • Quantitative Risk Analysis
    • Risk Response Planning
    • Risk Monitoring and Control

    Project Procurement Management

    • Plan Purchase and Acquisition
    • Plan Contracting
    • Request Seller Responses
    • Select Sellers
    • Contract Administration
    • Contract Closure

  • J.D. Meier's Blog

    30 Day Improvement Sprints

    • 12 Comments

    I'm using 30 day improvement sprints as a way to sharpen my skills.  I pick a focus to work on and I committ to improving it for a 30 day timebox.  Committing to 30 days of improvement in a focused area, is easier to swallow than changing for life.  However, improving an area for 30 days, is actually life changing.

    With 30 days, persistence and time are on my side.  It's a big enough time box that I can try different techniques, while building proficiency.  Using 30 days makes working through hurdles easier too.  A lot of the hurldles I hit in my first week, are gone by week 2.  Little improvements each day, add up quickly.  I look back on how many things I tried for a week and stopped thinking I hadn't made progress.  The trick was, I didn't get to week 2 to see my results.  Lesson learned!

    Related Posts

  • J.D. Meier's Blog

    Get Lean, Eliminate Waste

    • 4 Comments

    If you want to tune your software engineering, take a look at Lean.  Lean is a great discipline with a rich history and proven practices to draw from.  James has a good post on applying Lean principles to software engineering.  I think he summarizes a key concept very well:

    "You let quality drive your speed by building in quality up front and with increased speed and quality comes lower cost and easier maintenance of the product moving forward."

    7 Key Principles in Lean
    James writes about 7 key principles in Lean:

    1. Eliminate waste.
    2. Focus on learning.
    3. Build quality in.
    4. Defer commitment.
    5. Deliver fast.
    6. Respect people.
    7. Optimize the whole.

    Example of Deferring Commitment
    I think the trick with any principles is knowing when to use them and how to apply them in context.  James gives an example of how Toyota defers commitment until the last possible moment:

    "Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design."

    Examples in Software Engineering
    From a software perspective, what I've seen teams do is prototype multiple solutions to a problem and then pick the best fit.  The anti-pattern that I've seen is committing to one path too early without putting other options on the table.

    A Lean Way of Life
    How can you use Lean principles in your software development effort?  ... your organization?  ... your life?

    More Information

  • J.D. Meier's Blog

    The Zen of Zero Mail

    • 14 Comments

    You too can have a zero mail inbox, if you choose to.  I chose to go zero mail in my inbox when I first joined Microsoft years ago, and I'm glad I did.  With a single glance, I know whether I have new mail to deal with.  I never have to scroll to see what my next actions are.   At a more basic level, an empty inbox feels good.  I thought it was just me, but others say the same. 

    Proven Over Time
    It was tough when I first joined Microsoft.  My inbox drove me.  Eventually, I learned how to drive my inbox.  I studied the masters around me.  I also studied those that failed (there's no failure, only lessons.)  I refined my approach over the years.  Since then, I've successfully taught my mentees and others how to spend less time on administration and more time on results.  Now I'm sharing with you.

    Slides
    Here's a short deck that steps you through and highlights the keys:

    Note
    Normally, I work with my mentees one-on-one and tailor the approach for their particular scenario.  It's a learning by doing approach.  While I've blogged about clearing your inbox before, this is an experiment in how effectively I can share techniques in slides.  If it works out, I'll do additional slides on focused topics.  The more I can reduce friction around sharing, the more I can share.  If you have tips or tricks for improving my slide sharing approach, send my way.

  • J.D. Meier's Blog

    Architecture Frame

    • 10 Comments

    As part of our patterns & practices App Arch Guide 2.0 project, we've put together an arch frame.  The arch frame is simply a collection of hot spots.  These aren't just any hot spot though.  These hot spots represent key engineering decisions, anti-patterns, and opportunities for improved designs for more effective technical architectures.  This Arch Frame is part of the larger App Arch Meta Frame.  Think of it as an important branch off the main tree.  It serves as a lens to cut through a lot of information to get to the most meaningful and actionable guidance.

    Categories
    The following categories are the "hot spots" in the architecture frame:

    • Authentication and Authorization
    • Caching and State
    • Communication
    • Composition
    • Concurrency and Transactions
    • Configuration Management
    • Coupling and Cohesion
    • Data Access
    • Exception Management
    • Logging and Instrumentation
    • User Experience
    • Validation
    • Workflow

    What you might notice about the hot spots is that they map to common cross-cutting concerns when building applications.  You also might notice that the hot spots map to various patterns & practices solution assets.  For example, Enterprise Library includes blocks for caching, data access, exception management, logging, validation ... etc.  The categories also map to very actionable decisions where you there's relevant principles, patterns, and practices.  These buckets also contain many anti-patterns.  The worst anti-patterns are the "do overs."  Nobody wants a "do over" architecture.

    Key Engineering Decisions
    This table summarizes the key engineering decisions within each hot spot:

    Category Key Engineering Decisions
    Authentication and Authorization
  • How to store user identities.
  • How to authenticate callers.
  • How to authorize callers.
  • How to flow identity across layers and tiers.
  • Caching and State
  • How to choose effective caching strategies.
  • How to improve performance with caching.
  • How to improve security with caching.
  • How to improve availability with caching.
  • How to keep the cached data up to date.
  • How to determine when and why to use a custom cache.
  • How to determine what data to cache.
  • How to determine where to cache the data.
  • How to determine the expiration policy and scavenging mechanism.
  • How to load the cache data.
  • How to monitor a cache.
  • How to synchronize caches across a farm.
  • How to determine which caching technique provides the best performance and scalability for a specific scenario and configuration.
  • How to determine which caching technology complies with the application's requirements for security, monitoring, and management.
  • Communication
  • How to communicate between layers / tiers.
  • How to perform asynchronous communication.
  • How to pass sensitive data.
  • Composition
  • How do design for composition.
  • How to design loose coupling between modules.
  • How to handle dependencies in a loosely coupled way.
  • Concurrency and Transactions
  • How to handle concurrency between threads.
  • How to choose between optimistic and pessimistic concurrency.
  • How to handle distributed transactions.
  • How to handle long running transactions.
  • How to determine appropriate transaction isolation levels.
  • How to determine when compensating transactions are required.
  • Configuration Management
  • How to determine which information needs to be configurable.
  • How to determine where and how to store configuration information.
  • How to handle sensitive information.
  • How to handle configuration information in a farm/cluster.
  • Coupling and Cohesion
  • How to separate concerns
  • How to structure the application.
  • How to choose an appropriate layering strategy.
  • How to establish boundaries.
  • Data Access
  • How to manage database connections.
  • How to handle exceptions.
  • How to improve performance.
  • How to improve manageability.
  • How to handle blobs.
  • How to page records.
  • How to perform transactions.
  • Exception Management
  • How to handle exceptions.
  • How to log exceptions.
  • Logging and Instrumentation
  • How to determine which information to log.
  • How to make the logging configurable
  • User Experience
  • How to improve task efficiency and effectiveness.
  • How to improve responsiveness.
  • How to improve user empowerment.
  • How to improve look and feel.
  • Validation
  • How to determine where and how to perform validation.
  • How to validate for length, range, format, and type.
  • How to constrain and reject input.
  • How to sanitize output.
  • Workflow
  • How to handle concurrency issues within a workflow
  • How to handle task failure within a workflow
  • How to orchestrate processes within a workflow
  •  

    Key Issues
    This table summarizes the key issues within each hot spot:

    Category Key Issues
    Authentication and Authorization
  • Clear text credentials in configuration files
  • Passing clear text credentials over the network
  • Over-privileged accounts
  • Long sessions
  • Mixing personalization with authentication
  • Reliance on a single gatekeeper
  • Failing to lock down system resources against application identities
  • Failing to limit database access to specified stored procedures
  • Inadequate separation of privileges
  • Caching and State
  • Cache misses.
  • Failure to expire items
  • Poor cache design
  • Lack of a cache synchronization mechanism for scaling out.
  • Communication
  • Increased network traffic and latency due to chatty calls between layers.
  • Inappropriate transport protocols and wire formats.
  • Large data volumes over limited bandwidth networks.
  • Composition Tightly coupled modules Duplication of code
    Concurrency and Transactions
  • Blocking calls
  • Nongranular locks
  • Misuing threads
  • Holding onto locks longer than necessary
  • Inappropriate isolation levels
  • Configuration Management
  • Insecure administration interfaces
  • Insecure configuration stores
  • Clear text configuration data
  • Too many administrators
  • Over-privileged process accounts and service accounts
  • Coupling and Cohesion
  • Limited scalability due to server and resource affinity.
  • Mixed presentation and business logic, which limits your options for scaling out your application.
  • Lifetime issues due to tight coupling.
  • Data Access
  • Per user authentication and authorization when not required.
  • Chatty calls to database
  • Intersperse of business logic
  • Exception Management
  • Leaving system / application in unstable state
  • Revealing sensitive information to end users.
  • Using exceptions for logic
  • Not logging enough details about the exception.
  • Logging and Instrumentation
  • Lack of logging and instrumentation
  • Too fine grained logging and instrumentation
  • Not making logging and instrumentation configurable option at runtime
  • Failure to log business critical functionality.
  • User Experience
  • Inefficient or ineffective task support.
  • Poor responsiveness.
  • Disempowered users.
  • Validation
  • Application-only filters for malicious input
  • Non-validated input in the Hypertext Markup Language (HTML) output stream
  • Non-validated input used to generate SQL queries
  • Reliance on client-side validation
  • Use of input file names, URLs, or user names for security decisions
  • Workflow
  • Tight coupling
  • Inflexible processes
  • Race and deadlock issues
  •  

    Key Guidelines
    This table summarizes the key guidelines within each hot spot:

    Category Key Guidelines
    Authentication and Authorization
  • Consider single-sign on requirements.
  • Separate public and restricted areas.
  • Use account lockout policies for end-user accounts.
  • Support password expiration periods.
  • Be able to disable accounts.
  • Do not store passwords in user stores.
  • Require strong passwords.
  • Do not send passwords over the wire in plaintext.
  • Protect authentication cookies.
  • Use multiple gatekeepers.
  • Restrict user access to system-level resources.
  • Consider authorization granularity.
  • Caching and State
  • Avoid caching per-user data.
  • Avoid caching volatile data which is required by the user to be accurate and updated in real time.
  • Cache data that does not change very frequently or is completely static.
  • Do not cache shared expensive resources.
  • Cache transformed data, keeping in mind the data use.
  • Evaluate stateful versus stateless design.
  • Consider your state store options.
  • Minimize session data.
  • Free session resources as soon as possible.
  • Avoid accessing session variables from business logic.
  • Communication
  • Choose the appropriate remote communication mechanism.
  • Design chunky interfaces.
  • Consider how to pass data between layers.
  • Minimize the amount of data sent across the wire.
  • Batch work to reduce calls over the network.
  • Reduce transitions across boundaries.
  • Consider asynchronous communication.
  • Consider message queuing.
  • Consider a "fire and forget" invocation model.
  • Cut call chains with queues and caches as much as possible. Doing so will enhance the scalability and availability of the overall solution.
  • Push out asynchronous boundaries close to the user, service interfaces, and service agents, to isolate your service from external dependencies.
  • If you need to expose functionality as a synchronous operation, evaluate whether you can wrap an internally asynchronous operation as described in the following discussion
  • Composition
  • Avoid using dynamic layouts that are difficult to load and maintain.
  • Be careful with dependencies between components. Use abstraction patterns when possible to avoid issues with maintainability.
  • Consider creating templates with placeholders. For example use the Template View pattern to compose dynamic web pages to ensure reuse and consistency.
  • Consider composing views from reusable modular parts. For example use the Composite View pattern to build a view from modular, atomic component parts.
  • Use well-known design patterns to implement a composite interface containing separate modules or user controls where appropriate.
  • Modules should not directly reference one another or the application that loaded them.
  • Modules should use services to communicate with the application or with other modules.
  • Modules should not be responsible for managing their dependencies.
  • Modules should support being added and removed from the system in a pluggable fashion.
  • Concurrency and Transactions
  • Treat threads as a shared resource.
  • Pool shared or scarce resources.
  • Acquire late, release early.
  • Consider efficient object creation and destruction.
  • Consider resource throttling.
  • Reduce contention by minimizing lock times.
  • Balance between coarse- and fine-grained locks.
  • Choose an appropriate transaction isolation level.
  • Avoid long-running atomic transactions.
  • Configuration Management
  • Protect your administration interfaces.
  • Protect your configuration store.
  • Maintain separate administration privileges.
  • Use least privileged process and service accounts.
  • Coupling and Cohesion
  • Partition application functionality into logical layers.
  • Choose the proper locality for your objects based on your reliability, performance, and scalability needs.
  • Design for loose coupling.
  • Design for high cohesion.
  • Use early binding where possible.
  • Evaluate resource affinity.
  • Data Access
  • If your application uses a single database, use the database-specific data provider.
  • If you need to support multiple databases, you generally need to have an abstraction layer, which helps you transparently connect to the currently configured store.
  • Consider resource throttling.
  • Consider the identities you flow to the database.
  • Separate read-only and transactional requests.
  • Avoid unnecessary data returns.
  • Exception Management
  • Avoid revealing sensitive data to users.
  • Do not use exceptions to control application flow.
  • Use validation code to avoid unnecessary exceptions.
  • Do not catch exceptions that you cannot handle.
  • Be aware that rethrowing is expensive.
  • Preserve as much diagnostic information as possible in your exception handlers.
  • Logging and Instrumentation
  • Instrument your code up front.
  • Make your logging configurable.
  • User Experience
  • Measure effectiveness against scenarios.
  • Improve user responsiveness where possible.
  • Model from effective user design.
  • Validation
  • Validate for length, range, format, and type.
  • Constrain and reject input.
  • Sanitize output.
  • Don’t rely on client-side validation.
  • Workflow
  • Determine management requirements. If a business user needs to manage the workflow, you’ll need a solution that provides an interface that the business user can understand.
  • Determine how exceptions will be handled.
  • With human workflow, you need to consider the un-deterministic nature of humans. In other words, you can’t determine when a task will be completed, or if it will be completed correctly.
  • Use service interfaces to interact with external workflow providers.
  • If supported, use designers and metadata to define the workflow instead of code to define the workflow.
  • How To Provide Feedback
    We're still banging through the frame.  There's some rough spots.  We want to make sure we can map problems, principles, patterns, assets, and technologies to the right hot spots.  We want a prioritized list over a laundry list so we're still deciding what's in and what's out.  We'll add it to CodePlex shortly.  You can either comment here on my blog or wait until the frame is on CodePlex, and then provide comments in the Wiki.

    Additional Resources


    My Related Posts

Page 3 of 45 (1,101 items) 12345»