J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    MSF Agile Frame (Workstreams and Key Activities)

    • 1 Comments

    When I review an approach, I find it helpful to distill it to a simple frame so I can get a bird's-eye view.  For MSF Agile, I found the most useful frame to be the workstreams and key activities.  According to MSF, workstreams are simply groups of activities that flow logically together and are usually associated with a particular role.  I couldn't find this view in MSF Agile, so I created one:

    Workstream Role Key Activities
    Capture Project Vision Business Analyst Write Vision Statement; Define Personas; Refine Personas
    Create a Quality of Service Requirement Business Analyst Brainstorm quality of Service Requirements; Develop Lifestyle Snapshot; Prioritize Quality of Service Requirements List; Write Quality of Service Requirements; Identify Security Objectives
    Create a Scenario Business Analyst Brainstorm Scenarios; Develop Lifestyle Snapshot; Prioritize Scenario List; Write Scenario Description; Storyboard a Scenario
    Guide Project Project Manager Review Objectives; Assess Progress; Evaluate Test Metric Thresholds; Triage Bugs; Identify Risk
    Plan an Iteration Project Manager Determine Iteration Length; Estimate Scenario; Estimate Quality of Service Requirements; Schedule Scenario; Schedule Quality of Service Requirement; Schedule bug Fixing Allotment; Divide Scenarios into Tasks; Divide Quality of Service Requirements into Tasks
    Guide Iteration Project Manager Monitor Iteration; Mitigate a Risk; Conduct Retrospectives
    Create a Solution Architecture Architect Partition the System; Determine Interfaces; Develop Threat Model; Develop Performance Model; Create Architectural Prototype; Create Infrastructure Architecture
    Build a Product Developer Start a Build; Verify a Build; Fix a Build; Accept Build
    Fix a Bug Developer Reproduce the Bug; Locate the Cause of a Bug; Reassign a Bug; Decide on a Bug Fix Strategy; Code the Fix for a Bug; Create or Update a Unit Test; Perform a Unit Test; Refactor Code; Review Code
    Implement a Development Task Developer Cost a Development Task; Create or Update a Unit Test; Write Code for a Development Task; Perform Code Analysis; Perform a Unit Test; Refactor Code; Review Code; Integrate Code Changes
    Close a Bug Tester Verify a Fix; Close the Bug
    Test a Quality of Service Requirement Tester Define Test Approach; Write Performance Tests; Write Security Tests; Write Stress Tests; Write Load Tests; Select and Run a Test Case; Open a Bug; Conduct Exploratory Testing
    Test a Scenario Tester Define Test Approach; Write Validation Tests; Select and Run a Test Case; Open a Bug; Conduct Exploratory Testing
    Release a Product Release Manager Execute a Release Plan; Validate a Release; Create Release Notes; Deploy the Product

  • J.D. Meier's Blog

    How To Share Lessons Learned

    • 2 Comments

    I'm a fan of sharing lessons learned along the way.  One light-weight technique I do with a distributed team is a simple mail of Do's and Dont's.  At the end of the week or as needed, I start the mail with a list of dos and dont's I learned and then ask the team to reply all with their lessons learned.

    Example of a Lessons Learned Mail

    Collaboration

    • Do require daily live synchs to keep the team on the same page and avoid churn in mail.
    • Do reduce the friction to be able to spin up Live Meetings as needed.

    Guidance Engineering

    • Do index product docs to help build categories and to know what's available.
    • Do scenario frames to learn and prioritize the problem space.
    • Do use Scenarios, Questions and Answers, Practices at a Glance, and Guidelines to build and capture knowledge as we go.
    • Do use Scenarios as a scorecard for the problem space.
    • Do use Questions and Answers as a chunked set of focused answers, indexed by questions.
    • Do use Practices as a Glance, as a frame for organizing task-based nuggets (how to blah …)
    • Do use Guidelines for recommended practices (do this, don't do this … etc.)
    • Do create the "frame"/categories earlier vs. later.

    Personal Effectiveness

    • Do blog as I go versus over-engineer entries.
    • Do sweep across bodies of information and compile indexes up front versus ad-hoc (for example, compile bloggers, tags, doc indexes, articles, sites … etc.)

    Project Management

    • Don't split the team across areas.  Let the team first cast a wide net to learn the domain, but then focus everybody on the same area for collaboration, review, pairing …etc.

    Tools

    • Do use CodePlex as a channel for building community content projects.

    Guidelines Help Carry Lessons Forward
    While this approach isn't perfect, I found it makes it easier to carry lessons forward, since each lesson is a simple guideline.  I prefer this technique to approaches where there's a lot of dialogue but no results.  I also like it because it's a simple enough forum for everybody to share their ideas and focus on objective learnings versus finger point and dwelling.  I also find it easy to go back through my projects and quickly thumb through the lessons learned.

    Do's and Don'ts Make Great Wiki Pages Too
    Note that this approach actually works really well in Wikis too.  That's where I actually started it.  On one project, my team created a lot of lessons learned in a Wiki, where each page was dedicated to something we found useful.  The problem was, it was hard to browse the lessons in a useful way.  It was part rant, part diatribe, with some ideas on improvements scattered here or there.  We then decided to name each page as a Do or Don't and suddenly we had a Wiki of valuable lessons we could act on.

  • J.D. Meier's Blog

    Quick and Dirty Getting Things Done

    • 4 Comments

    If you're backlogged and you want to get out, here's a quick, low tech, brute force approach.  On your whiteboard, first write your key backlog items.  Next to it, write down To Do.  Under To Do, write the three most valuable things you'll complete today.  Not tomorrow or in the future, but what you'll actually get done today.  Don't bite off more than you can chew.  Bite off enough to feel good about what you accomplished when the day is done.

    If you don't have a whiteboard, substitute a sheet of paper.  The point is keep it visible and simple. Each day for this week, grab a new set of three.  When you nail the three, grab more.  Again, only bite off as much as you can chew for the day.  At the end of the week, you'll feel good about what you got done.

    This is a technique I've seen work for many colleagues and it's stood the test of time.  There's a few reasons behind why this tends to work:

    • Whiteboards make it easy to step back, yet keep focus.
    • You only bite off a chunk at a time, so you don't feel swamped.
    • As you get things done, you build momentum.
    • You have constant visual feedback of your progress.
    • Unimportant things slough off.

    My Related Posts

  • J.D. Meier's Blog

    VSTS Guidance Projects Roundup

    • 5 Comments

    Here's a quick rundown of our patterns & practices VSTS related Guidance projects.   It's a combination of online knowledge bases, guides, video-based guidance and a community Wiki for public participation.  We're using CodePlex for agile release, before baking into MSDN for longer term.

    Guides

    Knowledge Bases

    • patterns & practices Performance Testing Guidance Wiki - This project is focused on creating an online knowledge base of how tos, guidelines, and practices for performance testing, including performance testing using Visual Studio Team System. It's a collaborative effort between industry experts, Microsoft ACE, patterns & practices, Premier, VSTS team members, and customers.
    • patterns & practices Visual Studio Team System Guidance Wiki - This project is focused on creating an online knowledge base of how tos, guidelines, and practices for Microsoft Visual Studio Team System. It's a collaborative effort between patterns & practices, Team System team members, industry experts, and customers.

    Video-Based Guidance

    Community Wiki

    Note that we're busy wrapping up the guides.  Once the guides are complete, we'll do a refresh of the online knowledge bases.  We'll also push some updated modules to Guidance Explorer.

    My 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

    Clearing Your Inbox

    • 9 Comments

    Today I helped a colleague clear their inbox.  I've kept a zero mail inbox for a few years.  I forgot this wasn't common practice until a colleague said to me, "wow, your inbox doesn't scroll."

    I didn't learn the zen of the zero mail inbox over night.  As pathetic as this sounds, I've actually compared email practices over the years with several people to find some of the best practices that work over time.  The last thing I wanted to do was waste time in email, if there were better ways.  Some of my early managers also instilled in me that to be effective, I needed to master the basics.  Put it another way, don't let administration get in the way of results.

    Key Steps for a Clear Inbox
    My overall approach is to turn actions into next steps, and keep stuff I've seen, out of the way of my incoming mail.  Here's the key steps: 

    1. Filter out everything that's not directly to you.  To do so, create an inbox rule to remove everything that's not directly To or CC you.  As an exception, I do let my immediate team aliases fall through.
    2. Create a folder for everything that's read.  I have a folder to move everything I read and act on.  This is how I make way for incoming.
    3. Create a list for your actions.  Having a separate list means you can list the actions in the sequence that makes sense for you, versus let the sequence in your inbox drive you.

    Part of the key is acting on mail versus shuffling it.  For a given mail, if I can act on it immediately, I do.  If now's not the time, I add it to my list of actions.  If it will take a bit of time, then I drag it to my calendar and schedule the time.

    Anti-Patterns
    I think it's important to note the anti-patterns:

    1. Using your inbox as a large collection of action and semi-action items with varying priorities
    2. Using your inbox as a pool of interspersed action and reference items
    3. Adopting complicated mail and task management systems

    My Related Posts

    1. Scannable Outcome Lists
    2. Using Scannable Outcomes with My Results Approach
  • J.D. Meier's Blog

    How To Do Tasks More Efficiently

    • 2 Comments

    Here's my short-list of techniques I use for improving efficiency on a given task:

    • Increase the frequency.  If I'm not efficient at something and I need to be, I start doing it more.  A lot more.  Frequency helps me get over resistance.  I also get more chances to learn little things each time that help me improve.   
    • Reduce friction.  This is important and goes in hand with increasing the frequency.  When I do something more, I can quickly find the friction points.  For example, I was finding that pictures were piling up on my camera.  The problem was I needed my camera's cradle to transfer my pics.  When I got my new camera, I could transfer pics through the memory disk without the cradle and the friction was gone.  It was a world of difference.  I pay attention to friction points now in all the recurring tasks I need to do.
    • Model the best.  If I look around, I can usually find somebody who's doing what I want to do, better than I'm doing it.  I learn from them.  For example, when I was doing an improvement sprint on making videos, I learned from Jason Taylor, Alik Levin, and Alex Mackman, since they were all doing videos for some time and had lessons to share.
    • Batch the tasks.  There's two ways I batch tasks.  First, I gather enough so that when I do them, I'll learn in a batch.  Second, I look for way to split the work and to batch the workstreams.  For example, when I was working on an improvement sprint for speech to text, I made very little progress if I tried to dictate and edit.  I made much more progress when I dictated in batch, and then edited in batch.  It was a simple shift in strategy, but made a world of difference.

    While each technique is useful, I find I improve faster when I'm using them together.  It's synergy in action, where the sum is better than the parts.

    My Related Posts

  • J.D. Meier's Blog

    Timebox Your Day

    • 5 Comments

    Grigori Melnik joined our team recently.  He's new to Microsoft so I shared some tips for effectiveness.  Potentially, the most important advice I gave him was to timebox his day.  If you keep time a constant (by ending your day at a certain time), it helps with a lot of things:

    • Worklife balance (days can chew into nights can chew into weekends)
    • Figuring our where to optimize your day
    • Prioritizing (time is a great forcing function)

    To start, I think it helps to carve up your day into big buckets (e.g. administration, work time, think time, connect time), and then figure out how much time you're willing to give them.  If you're not getting the throughput you want, you can ask yourself:

    • are you working on the right things?
    • are you spending too much time on lesser things?
    • are there some things you can do more efficiently or effectively?

    To make the point hit home, I pointed out that without a timebox, you can easily spend all day reading mails, blogs, aliases, doing self-training, ... etc. and then wonder where your day went.  Microsoft is a technical playground with lots of potential distractions for curious minds that want to grow.  Using timeboxes helps strike balance.  Timeboxes also help with pacing.  If I only have so many hours to produce results, I'm very careful to spend my high energy hours on the right things.

    My Related Posts

  • J.D. Meier's Blog

    How To Research Efficiently

    • 7 Comments

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

    Initial Folders

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


    Key Points

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

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

    My Related Posts

  • J.D. Meier's Blog

    Performance Testing Guide Beta 1 is Available

    • 6 Comments

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

    Contents at a Glance

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


    Chapters

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

    About Our Team

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

    TFS Guide Beta 1 is Available

    • 20 Comments

    Today we released our Beta 1 of Team Development with Visual Studio Team Foundation Server Guide.  It's our Microsoft playbook for TFS.  This is our guide to help show you how to make the most of Team Foundation Server.  It's a distillation of many lessons learned.  It's a collaborative effort among product team members, field, industry experts, MVPs, and customers.

    Contents at a Glance

    • Part I, Fundamentals
    • Part II, Source Control
    • Part III, Builds
    • Part IV, Large Project Considerations
    • Part V, Project Management
    • Part VI, Process Guidance
    • Part VII, Reporting
    • Part VIII, Setting Up and Maintaining the Team Environment


    Chapters

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

    About Our Team

    • Prashant Bansode - Prashant's an experienced guidance builder and a master of execution.  He's a solid pillar on the team.
    • Jason Taylor - Jason's a master of results.  I've worked with Jason across a few projects.  He always hits the ground running and accelerates from there.
    • Alex Mackman - I worked with Alex on Building Secure ASP.NET Applications, Improving Perf and Scale, and Improving .NET Performance and Scalability, so it's great to have him back.
    • Kevin Jones - Kevin is new to our team, but getting up to speed fast.  He brings a wealth of Visual Studio Team System experience to the table.


    Contributors and Reviewers
    Here's our contributors and reviewers so far:

    • Microsoft: Ajay Sudan; Ajoy Krishnamoorthy; Alan Ridlehoover; Alik Levin; Bijan Javidi; Buck Hodges; Burt Harris; Doug Neumann; Edward Jezierski; Eric Charran; Graham Barry; Jeff Beehler; Julie MacAller; Ken Perilman; Mario Rodriguez; Marc Kuperstein; Matthew Mitrik; Michael Puleio; Nobuyuki Akama; Paul Goring; Pete Coupland; Peter Provost; Rob Caron; Robert Horvick; Rohit Sharma; Sajee Mathew; Siddharth Bhatia; Tom Hollander; Venky Veeraraghavan
    • External: David P. Romig, Sr; Eric Blanchet; Leon Langleyben; Martin Woodward; Quang Tran; Sarit Tamir; Tushar More; Vaughn Hughes; Michael Rummier

     

  • J.D. Meier's Blog

    Put Your Thinking Hat On

    • 1 Comments

    I'm a fan of using different techniques for improving thinking. Here's a write-up on Six Thinking Hats.  This book presents a simple and effective thinking framework.  What I like about the approach is that it's both effective for individuals as well as a team.  What I also like about the approach is that rather than focus on trying to change personalities, it creates a way for different personalities to play well together.  Imagine the time you'll save in meetings!

    Because Six Thinking Hats uses the hats as a metaphor, nobody gets a label.  Instead, the entire team can put on the relevant hat for the task at hand: white, red, black, yellow, green, or blue.  Imagine the surprises you get when the dominantly data-driven put on their green hats and get creative.  Better yet, imagine what happens when the overly optimistic put on their black hats and play the "devil's advocate"?

    What's interesting is this type of mode switching already happens.  For example, in security we use white hats and black hats.  On my team, I often ask, "what's your gut say" to tap into intuition and emotions.  If I see the team too optimisitic, I ask "why won't this work?".

    I think having a simple set of metaphorical hats and rules for the game will really help improve thinking and collaboration, and avoid the stale-mates that can often happen in meetings.  As the author puts it, you "think your way forward versus judge your way forward."

  • J.D. Meier's Blog

    Feed Readers

    • 4 Comments

    Darren asks Which Feed Reader is Best?  I was going to just add a comment, but it quickly turned into a post.

    I've used Bloglines, Google.com, Google Reader, Live.com, Newzie, OMEA Reader, and RSS Bandit.  I know I've used more that I'm forgetting.  They all have their strengths and weaknesses, so finding the right match for my scenarios is the key.  They all seem to continue to improve, so I find I also have to go back and re-evaluate from time to time.

    For the rich desktop experience, I ended up using NewzieRob pointed me to it and I know he does a lot of feed reading and he too had tried a lot of readers.  What's interesting about Newzie is its use of color-coding to flag by time.  I also like the fact that it has multiple views, including a tree view, list view, news ticker view, and a today view.

    For my "webtop" experience, I end up mostly using Live.com so I could get to my feeds from any desktop.  I created pages for different topics.  This lets me chunk up my reading experience and never get overwhelmed.  The nice thing about a page view is it's easy to scan across. 

    When I help somebody get started reading feeds, if they have a Windows Live account, then I show them how to add pages and add feeds to Live.com, since I don't think it's obvious.  If they don't have a Windows Live account, then I have them download Newzie and help them add a few posts of their favorite topic, and then show them how to swtich views.

    My Related Posts

  • J.D. Meier's Blog

    The Better Adapted You Are, the Less Adaptable You Tend To Be

    • 10 Comments

    I was skimming The Secrets of Consulting and I came across this nugget: 

    “...Many years ago, Sir Ronald Fisher noted that every biological system had to face the problem of present versus future, and that the future was always less certain than the present. To survive, a species had to do well today, but not so well that it didn’t allow for possible change tomorrow. His Fundamental Theorem of Natural Selection said that the more adapted an organism was to present conditions, the less adaptable it tended to be to unknown future conditions. We can apply the theorem to individuals, small groups of people, large organizations, organizations of people and machines, and even complex systems of machinery, and can generalize it as follows: The better adapted you are, the less adaptable you tend to be...”
    Source: Gerald M. Weinberg, The Secrets of Consulting (New York, Dorset House Publishing, 1985) pp 29-30

    Along the same lines, I was scanning Lean Software Engineering and came across this nugget:

    "... When it comes to large-scale, creative engineering, the right processes for all the various teams in an organization depends on both people and situation — both of which are constantly changing. You can’t just adopt a particular process and be done with it.  So really the only “bad process” is one that doesn’t provide framework to reflect and permission to adapt..."
    Source: Avoid Dogma When Herding Cats

    This reminded me of a quote from Hereclitus - "Nothing endures but change."

    I'm a fan of adaptability and continuous improvement.  I think adaptability is a key ingredient for effectiveness.  I always reflect on and test how adaptable is my mindset? ... my approach? ... my tools? ... my teams? ... my organization? ... my company? ... etc.

  • J.D. Meier's Blog

    ARCast.net - Defending the Application

    • 1 Comments

    Ron talks security with Alik in ARCast.net - Defending the Application.  If you want to hear some practical advice on security, listen to Alik.  He's in the field doing security every day with customers.  It doesn't get anymore real-world than that.

    The key take-away for me is the focus on proven practices.  I have a belief that focusing on a set of core practices is more effective than chasing all the variations of bad symptoms.  For example, if you adopt a practice of constraining, rejecting and sanitizing input, and you verify input for length, range, format and type, you tackle injection issues (cross-site scripting, SQL injection, SQL truncation ... etc.) at the source.

    At one point in the interview, Ron mentions that attackers share information all the time.  Unfortunately, security is a game of what you don't know can hurt you.  That's why I think community efforts and knowledge bases are a must.  I'm glad to see more information sharing in blogs.  I'm also glad to see efforts like the Open Web Application Security Project (OWASP).  It's also why I try to share as much as possible through patterns & practices security guidance, Guidance Explorer, and SecurityGuidanceShare.com.

     

  • J.D. Meier's Blog

    Per's Blogging

    • 1 Comments

    Per Vonge Nielsen is blogging! He's been my manager for several years at patterns and practices.  He's also been a mentor for myself and many others, so it's great to see him share his learnings more broadly.   Per has a way of distilling information down into the essential insights, which is a treat in today's information overloaded world.

    Enjoy Per's first post - Divide and Conquer – one step at a time.

  • J.D. Meier's Blog

    Security Guidance Share Experiment

    • 3 Comments

    SecurityGuidanceShare.com is an experiment.  I'm testing different ways to maintain and share a large body of guidance.  I'm also exploring ways to factor and maintain a comprehensive set of more stable principles and practices, while dealing with more volatile, technology-specific information.

    I'd like your feedback on

    1. Overall organization of the information (it's a massive body)
    2. Usability of the chunks (can you grab just what you need? are the chunks right-sized?)
    3. Ability to find your way around

    My two favorite features:

    1. All Pages - this let's me quickly see the knowledge base at a glance.
    2. Inspection Questions - these are factored so you can chunk up your inspections.

    Comment here or send mail to SecNet.

  • J.D. Meier's Blog

    Jason Taylor is Blogging

    • 1 Comments

    Are you experiencing anxiousness, self-doubt or guilt?  It might not be your fault.  A parasite might be controlling your mind.  Jason explains how in Mind Control and the Friendly Mouse.

    I've worked with Jason for a few years from building software to writing guidance.  He's fast and effective.  We regularly swap techniques for getting results.  He's got a gift for distilling insights into action.  He shares that gift in his blog.

    Check out Jason Taylor's blog - The Good Life, to learn:

    • How to be an effective manager
    • How to be an effective leader
    • How to prioritize tough decisions

    You can also use his blog to learn how to recover from repetitive stress injuries.

    Jason's currently working with me and Prashant on the patterns & practices Visual Studio Team System Guidance project.

  • J.D. Meier's Blog

    Incremental Environments for Performance Excellence

    • 2 Comments

    Mark Tomlinson shared an emerging industry practice with me.  Customers are setting up incremental environments.  The environments are incremental steps from a developer environment to production.
     
    Incremental Environments

    1. Component-level performance testing. (close to dev)  The lab is setup with debuggers and profilers - anything a developer would need to investigate issues.
    2. Application performance testing.  A single "slice" of architecture, good for scale-up and optimization/tuning); usually dedicated for optimization or tuning of a single application/system; still have debuggers and profilers setup.
    3. Performance integration.  This is still the basic "slice" of architecture, but now bring into play other applications or systems; usually has multiple applications and supporting technologys that mutually get loaded (e.g. IIS and AD); network diagnostic tools and debuggers may be used here sometimes.
    4. System performance and stress.  Larger performance testing with scale-out scenarios, load balancing, failover; larger sized systems get more load - so you see more stressing of entire system resources, esp. network; often just for 1 application, but also for multiple integration testing.
    5. Large-scale integration and performance.  Multiple applications, with everything needed to prove business needs will be met; usually without some security and perhaps some 3rd-party integrations; usually not a stress testing environment - e.g. virtual users are set to generate real-world pacing and load.
    6. Pre-production simulation.  This is just like the real thing - full sized system, with full security and network topology (only not production); used both for internally built applications, and 3rd-party solutions which must be integrated; production repro's, patches, fixes, etc can be tested here safely.

    There's no strict rule for how many of each type of environment, and the most sohpisticated setup has multiple physical environments/labs which could be used for any of each purpose.  The beauty of this approach is that instead of having a great big wall to throw your application over, it's a series of incremental hurdles.  Each hurdle represents increasing requirements and constraints. 
     
    This approach is also great for Centers of Excellence.  A Center of Excellence team can build the environment to reflect and codify their practices.   The Center of Excellence team can also harvest and share the lessons learned to help teams over each incremental step.

  • J.D. Meier's Blog

    Baking Performance Into the Life Cycle

    • 2 Comments

    To engineer for performance, you need to embed a performance culture in your development life cycle, and you need a methodology. When you use a methodology, you know where to start, how to proceed, and when you are finished.

    Keys to Performance Engineering
    These are fundamental concepts to performance engineering:

    • Set objectives and measure.
    • Performance modeling helps you design performance for your scenarios.
    • Measuring continues throughout the life cycle and helps you determine whether you are moving towards your objectives.

    High ROI Techniques
    These are some of the most effective techniques we use to directly impact performance results:

    • Performance Objectives
    • Performance Design Guidelines
    • Performance Modeling
    • Performance Design Inspections
    • Performance Code Inspections
    • Performance Testing
    • Performance Tuning
    • Performance Deployment Inspections

    Key Notes

    • Think about performance up front versus after the fact.  If performance isn't a part of your scenarios, you're ignoring your user's experience, or you're ignoring your businesses.  Don't expect users to ask for performance.  They just expect it.
    • Use objectives and constraints to set boundaries.  Objectives tell you how much to invest in performance and what good looks like (for users, for the system, and for the business).
    • Use Objective-driven inspections over code reviews.  Don't tune your code for tuning's sake.  Know what good looks like.  Model and measure to know where to spend your time.  (Make sure your ladder is up against the right wall!)
    • Use design guidelines to make performance actionable.  Build a repository for your performance knowledge.  Wikis are great for this.  Capture your insights as principles, patterns, guidelines, ... etc.  Don't think of this as a blanket set of rules to follow.  Think of it as a knowledge base that you and your teams can draw from when desiging solutions, doing inspections, tuning performance ... etc. 

    More Information
    You can find more about the concepts above at:

  • J.D. Meier's Blog

    Lean Software Engineering

    • 1 Comments

    I'm jazzed to see Corey and Bernie on the blog scene.  They're partners in crime on a Lean Software Engineering blog.  They have real advice for real people doing software.

    Why listen to what Corey and Bernie have to say?  They know what they're talking about from experience.  They have the knowledge that can turn your software engineering around, if you need it.  A lot of what they know, is not well known (or at least not applied), so their blog is something of a gateway to a world of better software engineering.

    Whether you shape software, build it, or manage it, you'll find insights you can use.  Here's some of the things you'll learn:

    • How do you determine the minimum deployable feature set?
    • What essential principle allows Lean development to be something more than Agile?
    • How to take an evolutionary approach to software process change?
    • Why is quality NOT the fourth variable in the project triangle?
    • How do you aggregate decentralized knowledge?
    • What happens when single-piece flow meets the V model?
  • J.D. Meier's Blog

    patterns & practices Security Engineering Explained

    • 4 Comments

    I don't think our patterns & practices Security Engineering Explained guide is very findable, so I'm blogging it.  This could very well be the short guide that forever changes how you do security engineering.  The techniques in the guide are timeless and time-tested.

    TOC

    • Chapter 1: Security Engineering Approach
    • Chapter 2: Security Objectives
    • Chapter 3: Security Design Guidelines
    • Chapter 4: Threat Modeling
    • Chapter 5: Security Architecture and Design Review
    • Chapter 6: Security Code Review
    • Chapter 7: Security Deployment Review

    It's not a complicated methodology.  Instead, it's a set of techniques that have proven to  be the most valuable. How do we know?  Customer case after customer case.

    Incremental Adoption
    The beauty of this approach is that you don't have to adopt them all at once.  You can pick and choose the technique you see fits your software life style.  Here's some examples:

    • If I was a developer, I might start with the Security Code Inspections.
    • If I was an independent security consultant, I might first master Threat Modeling or perhaps build services around Security Design Inspections or Security Code Inspections.
    • If I was an architect, I might first master Threat Modeling and Security Design Inspections, as well as how to identify security objectives.
    • If I was a dev manager, I might find an iterative and incremental way to integrate  Threat Modeling, Security Design Inspections, Security Code Inspections, and Security Deployment Inspections into my software development life cycle.
    • If I was in charge of system administration, I would adopt Security Deployment Inspections.  I would also build threat models of the network and servers that the application teams can reuse for their application or product-line threat models.

    (Sorry - we don't have a set of patterns & practices guidance on performing specific security testing techniques at this time, though I think it's important and I have done some R&D projects in this area.)

    It's worth pointing out that the security techniques baked into Visual Studio Team System use our security engineering approach.  For example, you'll find our threat modeling templates in the MSF Agile and MSF for CMMI process guidance.

    How to Get the Guidance

    Team
    Here's members of the original team that have blogs:

  • J.D. Meier's Blog

    Guidance on Managing Source Control Dependencies in Team System Now Available

    • 2 Comments

    Our Explained: Managing Source Control Dependencies in Visual Studio Team System is now available.   I've seen several questions around handling source control dependencies so hopefully this guidance will help you spiral down on solutions that work for you. This guidance  covers dealing with the following dependencies:

    • Source code and binary references
    • Web service references
    • Database references

    You can read it online or download the PDF.

  • J.D. Meier's Blog

    How To Reference Web Services and Databases During Development

    • 2 Comments

    One technique for pointing your Web services and database references to alternate locations during development is to use a user.config file.  Although you could change your app.config references directly, using a level of indirection keeps your production settings intact while carving out just the references to your Web services and database connections.

    To use this approach, you point your app.config file to a user.config file.  You then store your user.config file with production settings in source control.  Each user changes their user.config file to point to the dev or test locations, but they don't check this in.

    In .NET 1.1, you can use the approach outlined in "Managing Dependencies" from Team Development with Visual Studio .NET and Visual SourceSafe.

    In .NET 2.0, you can use configSource to redirect from your app.config to user.config.

    Referencing Web Services from WinForms
    In a WinForms application, you would do the following:
    1.  Add a Web service reference to your WinForm.  This will add an app.config file with settings for the Web service:
            <WindowsApplication1.Properties.Settings>
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
            </WindowsApplication1.Properties.Settings>
    2.  Add an application configuration file and name it user.config
    3.  Delete all the text in user.config
    4.  Copy the relevent settings from your app.config to your user.config
            <WindowsApplication1.Properties.Settings>
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
            </WindowsApplication1.Properties.Settings>
    Important  - Your user.config file should only the settings above.
    5.  In app.config, use configSource to redirect from app.config to user.config
            <WindowsApplication1.Properties.Settings configSource="user.config">
      <!--
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
      -->
            </WindowsApplication1.Properties.Settings
    IImportant - comment out the settings, since you will now be using the settings in user.config
    6.  change the "Copy to Output Directory" property of the user.config file from "Do not copy" to "Copy if newer"

    Referencing Web Services from WebForms
    In an ASP.NET application, you would do the following:
    1.  add a Web services reference.  This would create settings in Web.config
     <appSettings>
     <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
     </appSettings>
    2.  Add a new web.config file and rename it to user.config
    3.  Delete all the text in the user.config file.
    4.  copy appSettings from web.config to user.config
     <appSettings>
     <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
     </appSettings>
    Important  - Your user.config file should strictly have only the settings above.
    5.  In web.config, use configSource to redirect from app.config to user.config
     <appSettings configSource="user.config">
      <!--
      <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
      -->
     </appSettings>
    Important - comment out the settings, since you will now be using the settings in user.config

    Referencing Database Connections from WinForms
    To reference a database from a Winform application, you would do the following:
    1.  Add an application configuration file and name it app.config
    2.  Add a reference to the configuration dll (System.Configuration)
    3.  Add an application configuration and rename it to user.config file
    4.  Add your connection string in app.config
     <?xml version="1.0" encoding="utf-8" ?>
     <configuration>
      <connectionStrings>
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
      </connectionStrings>
     </configuration>
    5.  Test your connection string
               string connectionString = ConfigurationManager.ConnectionStrings["test"].ConnectionString;
               using (SqlConnection connection = new SqlConnection(connectionString))
                {
                    connection.Open();
               }
    6.  Copy your connectionStrings from app.config to user.config
      <connectionStrings>
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
      </connectionStrings>
    Important - this should be the only text in your user.config
    7.  In app.config, redirect to user.config using configSource
     <connectionStrings configSource="user.config">
      <!--
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
       -->
      </connectionStrings>
    Important - comment out the settings, since you will now be using the settings in user.config 
    8.  On your user.config file, change the "Copy to Output Directory" property from "Do not copy" to "Copy if newer"

    For more information, take a look at Explained: Managing Source Control Dependencies in Visual Studio Team.

  • J.D. Meier's Blog

    Team Foundation Source Control Guidelines Now Available

    • 4 Comments

    Our Team Foundation Source Control Guidelines are now available.  You can read the Team Foundation Source Control Guidelines online in HTML or you can download the Team Foundation Source Control Guidelines in PDF.  The guidelines are part of our patterns & practices Visual Studio Team System Guidance Project.  We use the guidelines to encapsulate strategies and convey recommendations.  You can quickly skim the guidelines to checkpoint your understanding of some of the proven and emerging practices for Team Foundation Source Control.  We write each guideline using a "what to do", "why" and "how" approach to help make them easy to consume. 

    Team Foundation Source Control Guidelines is complimentary to our Team Foundation Source Control Practices at a Glance and our Team Foundation Source Control Questions and Answers.

Page 40 of 46 (1,146 items) «3839404142»