J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Video-Based Guidance Experiment

    • 3 Comments

    We're piloting some video-based guidance.  Here's what I want to accomplish for the videos:

    • Factor "What Is" from "How To" type videos (i.e. reference vs. action)
    • Do more, smaller videos vs. a few larger videos (modular vs. monolithic)
    • Show me how vs. just tell me how
    • Outcome-based videos (walk away with actionable insights)
    • Share strategies and approaches that sometimes don't across in just text

    For the user experience:

    • Ability to quickly browse an index of the videos
    • Ability to preview the videos inline
    • Ability to download and watch the videos at your convenience

    I'd like the videos to complement our text-based guidance modules (how tos, guidelines, checklists.)   While doing video is nothing new, I think the tough part for my team is figuring out:

    • How to balance prose-based guidance with video-based guidance
    • How to figure out the most useful videos to avoid signal to noise ratios
    • How to figure out the most effective channels and mediums

    I think a lot of our guidance can be more consumable in video form.  At the same time, I think some things aren't as useful in video.  I see video as a supplement to augment baking knowledge into plaintext (where we can efficiently search it, share it, tag it … etc.).

  • J.D. Meier's Blog

    Why 30 Day Improvement Sprints

    • 3 Comments

    Why 30 Day Improvement Sprints?  I get asked this often enough that I think I should distll the keys:

    • I can commit to something for 30 days.  Starting something without an end in sight, can be daunting.
    • It helps me deal with the now.
    • It's a timebox to deliver value to myself.
    • If I only do something ad-hoc now and then, I don't create an effective technique.  If I do a little each day, I find a way to reduce the friction.
    • It lets me parking lot things I want to work on.  I can put something on the backburner if I know I have a way to pick it back up.
    • It gives me a system to build a portfolio of improvements instead of cling to one-hit wonders here and there.
    • If it's daily, it becomes a habbit.  If it's something I do a few days a week or only for a week, I don't build a routine.
    • It's a long enough duration to see improvement or change approach.  I wonder how many things I tried in the past for a week, then stopped because I didn't see improvement?  If I'm not getting results, I have enough buffer to change my approaches or strategies.  Put it another way, 30 days gives me enough buffer to mess up.
    • It's easier to buy into incremental, daily improvement versus big up front improvement or change.
    • I'm a sprinter by nature.  While I've learned to pace by nurture, I prefer to put my all and do bursts.  It's when my energy is peak.

    Because my 30 Day Improvement Sprints are so effective for me, I have to resist the urge to bite off too many areas at once.  In general, I try to balance between mind, body, career, financial, and relationships.  My scannable outcome lists help me checkpoint.  As a pattern, I do tend to focus heavily on career, but now that I see it, I can change it, if it makes sense.

    Related Posts

  • J.D. Meier's Blog

    Journaling for Improvement

    • 1 Comments

    Whether I'm working on a 30 Day Improvement Sprint, or working through a complex problem, I find journaling is key.  By journal, I simply mean a personal log in some form that I can easily add to and review.   Journaling is key because I get to see at a glance, what I've accomplished.  I write down my little achievements each day.  When I don't, I tend to focus on everything I didn't do, instead of appreciating what I learned.  Those little, incremental distinctions add up fast.

    When I write down what I learn as I go, I have a log that I can scan for patterns.  For example, do my breakthroughs happen later versus earlier?  Do I usually get over a hump by bouncing an idea off somebody?  Do I have a pattern for learning that I can optimize?

    When I'm doing a 30 day improvement sprint, journaling is a must.  Otherwise, I forget when I started.  If I forget when I started, I don't know when I finish.  If I don't know when I finish, then I'm no longer sprinting towards the finish line.

    One of my favorite examples of extreme journaling is John Wooden.  Aapparently he kept an indvidual journal for every one of the players he coached.  He used journaling to tailor drills and customize training for each member of the team.  Whenever I don't feel like *bothering* to journal for myself, I think of the example John Wooden set, and I get back on the saddle again!

  • J.D. Meier's Blog

    Prioritizing Scannable Outcomes

    • 2 Comments

    How do I efficiently and effectively prioritize my day ... my week ... my life?  In an earlier post, I talked about using Scannable Outcome Lists.  For a quick reminder, this is simply a flat set of lists.  I name each list by project or area I'm working on (e.g. mind, body, career, project X, project Y, projec Z).  Inside each list, is my list of key outcomes.  Think of these as a list of lists -- a bird's eye view of the big picture, and then a drill-down view in each list. 

    I use this to quickly scan across my areas to remind me of what's important to work on.  This is the lowest overhead approach I've found so far to keep a wide radar scan, yet be able to drill in as needed.

    When I first started, it was easy to simply sort my list by area.  Now I find it helps me to sort this list by priority 0, 1, 2 and 99.  Priority 0 is for my continuous categories: mind, body, career, financial, relationship, personal dev, professional dev, and recurring.  I use recurring to remind myself of things like doing backups.  Priority 1 is for my most critical projects or most important areas, compared to my priority 2s which might be ideas I'm somewhat working on or starting to build momentum for, but not critical for success.   99 is on deck or backburner.  Collectively I think of this as managing action similar to Maslow's Hiearchy of Needs.

    To do this in Outlook, I have a single folder called Queue, to hold all my scannable outcome lists.  I drag a short-cut to Outlook's "favorite folders" for fast access.  I create a single post for each scannable outcome category.  I add priorities by assigning "Categories" to each post -- I tag each one with a 0, 1, 2 or 99.  I "Arrange" this older by "Categories", and then I custom sort by Subject.  This gives me a very fast sequenced view grouped by P0, P1, P2, P99 and then sorted alphabetically within each group.

    I start my days by scanning or updating my scannable outcome lists, then carving out the most important actions into my daily dos list.  The entire process generally takes me 5 minutes or less each day, except on Mondays where I have to spend a little more time to figure out outcomes for the week. 

    Related Posts

  • J.D. Meier's Blog

    patterns & practices Security Videos

    • 8 Comments

    We did a focused set of security videos with Keith Brown a while back.  The problem is they're not very findable (most customers I talk to aren't aware of them).  I added them to soapbox and listed them below to see if it helps (note soapbox may prompt you to log in):

    Input and Data Validation Videos

    They're designed to help you get key concepts behind some of our security guidance.   I also wanted to use somebody that was recognized in the field as somebody you could trust.  Keith's proven himself for a long time in the security community.  He also has the aura of an experienced trainer, which I think comes across in these videos.

  • J.D. Meier's Blog

    Security Mantras and Metaphors

    • 1 Comments

    After reading Alik Levin's Security Language That Everyone Understands and Michael Howard's Security Analogies are usually Wrong, I reflected on some mantras and metaphors our team found helpful during our various security adventures:

    • Know your threats.  If you know what you're up against, you can apply more relevant countermeasures as well as make better trade-off decisions.
    • Secure the network, host and application - this was our team's attempt to bridge the gap between app + infrastructure, and catch the security issues that fall through the cracks.  
    • Bake security into your application life cycle - we used this a lot when we met with customers while building Improving Web Application Security: Threats and Countermeasures.  I wanted to convey systematic and repeatable as well as to think in terms of life cycle practices.  It became our favorite hallway soundbyte.

    I've found these helpful too:

    • Your only as secure as your weakest link - this always invokes the question, how do you find your weakest link?  I think the trick is actually doing a threat model and a fault tree model, then figuring out the weakest links among your paths that matter most.
    • Defend your code.  Some developers like this one because it's proactive and empowering.
    • Design for securability.  I see securability described on MSDN, but I think more in terms of baking in the ability to improve the security posture or reduce the attack surface.

    As with any verbage or mental models, their usefulness varies and really depends on the context.  I like keeping my toolbelt full of options so I can choose what's most useful for the job at hand.  I do have some more favorites, but I'll save those for another day.

  • 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

    Worst Things First

    • 2 Comments

    This a practice I learned long ago and it's actually helpful whether it's day to day or building software. It's doing worst things first.

    It's human nature to move away from pain.  Sometimes I have a meeting or a conversation or even just a task for the day that I'm not looking forward to.   I'm not talking about the stuff I can ignore forever.  I'm talking about stuff that needs to happen sooner rather than later, that I won't enjoy doing.

    If I push those things to the end of the day or the end of the week, they loom.  Why loom longer than necessary?  That's draining.  Somebody long ago gave me the tip worst things first and I didn't realize it's actually become one of my most effective habbits.

    One of my mentees is going to combine worst things first with a 30 day improvement sprint to see how much energy they get back and how much more they get done.  I think this is a great experiment and I look forward to their results.

  • J.D. Meier's Blog

    Life's an Experiment

    • 3 Comments

    It's amazing how much the metaphors we use can be enabling or disabling.  For example, I used to think "in life there are no second chances" or "you never get a second chance at first impressions."  Once I adopted, "life's an experiment", it was much more enabling.  It means, changing from getting everything right up front to boxing my risks, trying more, and learning and adapting as I go.

    My manager is very much into experiments around impact and improvement.  He's got a research background, but he's into applied research.  That works great for me because I'm a fan of learning what works over theorizing endless possibilities.

    For me, the keys to metaphors are knowing which ones I use, and which ones are limiting.  I always need to ask, what's the most enabling metaphor for the situation I'm in.  What will make me more resourceful?  For example, in a group like patterns & practices, experimenting and continuous improvement come with the job.

    I'll have more to say on metaphors another day, but in the meantime, I'll leave you with this ... do you know your 3 most enabling metaphors? ... do you know your 3 most limiting?  (hint - limits and opportunities are in the eye of the beholder ... whether you think you can or can't, you're right)

  • J.D. Meier's Blog

    Hacking Web Applications Exposed, 2nd Edition

    • 1 Comments

    I like Hacking Web Applications Exposed, second edition.  I really do.  Here's the foreword I wrote:

    "Reveals the magic behind the attacks that are so pervasive on the Web today.  Knowing the attacks is a first step towards figuring out effective countermeasures.  The authors's style makes the information real and practical, while sharing their real-life experience."

    Joel Scambrary, Mike Shema, and Caleb Sima are the authors.  What you might know about Joel Scambrary is his previous Hacking Exposed books.  What you might not know about him is that he ran the security operations for MSN.  I worked closely with Joel, during our Improving Web Application Security:Threats and Countermeasures days.  He shared my passion for chunking up information to deal with tough problems.  We had lots of deep conversations about using buckets to break security down into manageable chunks and driving action.  I miss our talks.

    I first got to see Caleb Sima in action at one of our Microsoft hosted security events.  He's one of the most entertaining presenters I've seen.  He walked through a Web attack weaving a story of suspense and drama, full of amusing twists and turns.

    Bottom line - the book is insightful, practical, and the authors do a great job of interspersing actionable nuggets throughout. 

  • J.D. Meier's Blog

    Performance vs. Load vs. Stress Testing

    • 5 Comments

    This conversation (er, debate) comes up a lot.  What's the difference between performance, load and stress testing?  I'm sure there's tons of *official* definitions.  At the end of the day, I think about them like this:

    • Performance - is about response, time lapses, duration ... etc.
    • Load testing - is about test behavior under normal/peak workload conditions.  Load is more about characterizing / simulating your actual workload.
    • Stress testing - is about surfacing issues under extreme conditions and resource failures.

    I could say more, but sometimes less is better.  If you want to read more, check out our patterns & practices Performance Testing Guidance Project on CodePle  or browse through Scott Barber's exhaustive collection of performance testing articles.

  • J.D. Meier's Blog

    Team Foundation Server Branching Guidance Now Available

    • 3 Comments

    The Team Foundation Server Branching Guidance whitepaper is now available!  It's a comprehensive whitepaper that covers strategies, patterns and anti-patterns for branching and merging with TFS.  You can view the branching guidance online or you can download the PDF version.

    Branching Guidance Index

    • Introduction
    • Parallel Development
    • Branching Defined
    • Creating Isolation in Team Foundation Server
    • General Branching Structure Guidance
    • Branching Strategies
    • Broad Areas of Branching Isolation
    • Creating Your Branching Strategy
    • Defining Your Code Promotion Model
    • Feature Crews: How Microsoft Does It
    • End-to-End Implementation Scenario
    • Appendix

    My team works closely with Graham and Mario of the Branching Guidance team as we build out our patterns & practices VSTS Guidance Project.  We're sharing learnings and synchronizing recommendations as we go along.   We'll be adding more cross-references to the Branching Guidance Project and VSTS product documentation on MSDN from our guidance so you can easily hop for more information. 

  • J.D. Meier's Blog

    5 Tips for Blogging

    • 2 Comments

    Here's some quick blogging tips I shared with a colleague, that they found helpful:

    1. Have a purpose or a theme -- I find having a simple purpose helps.  For example, my one-liner for me is to journal my Microsoft adventures.  Within that, I'll tend to focus on shaping software, project management, and effectiveness.
    2. Know what you want from blogging -- if you don't have a compelling why, you'll lose the path.  Your's might be *share insights and lessons learned*, or *build a sounding board* or *influence change one reader at a time* ... etc.  It's whatever is compelling for you, and remind yourself when you need a boost.  For me, it's personal growth and sharing what I learn with others.
    3. Schedule your blog time -- it's not tough to write stuff; it's tough to sit down to write it.  Make the time first, and the creativity will happen.
    4. Post "good enough" vs. fit and finish -- if you always aim for the long-shot, you'll miss great posting opportunities along the way.
    5. Do a blogging 30 day improvement sprint -- Seriously.  You'll learn a lot up front, that you can use over a life time.  While a piecemeal approach over time works too, I think this is a case where you can learn a lot in batch. There's a lot to be said for little improvements for 30 days.  Even if that means asking and finding one good blogging question per day.  Most importantly use this sprint to find your rhythm.  Start off more frequently to become more efficient, then choose whether you want to do daily or weekly.
  • J.D. Meier's Blog

    Building a Custom Set of Guidance with Guidance Explorer

    • 1 Comments

    Today I was reminded of the powerful scenario for building a custom set of guidance on the fly using Guidance Explorer.  One of the scenarios for Guidance Explorer that's probably not well known, is the ability to generate MS Word documents.  You can also save to HTML or export to XML.  The idea was that you could build a custom set of guidance by grabbing the guidance modules you wanted. 

    In my case, I needed to quickly create two documents -- a set of ASP.NET 2.0 security guidelines and a set of ASP.NET 2.0 security checklist items.  To do this using Guidance Explorer, I took the following steps:

    1. created a new view and named it ASP.NET 2.0 Security Guidelines
    2. filtered the guidelines for ASP.NET 2.0 and Security
    3. dragged the guidelines into my new view
    4. clicked my view and then dragged the Category field over to the far left
    5. sorted the Category field.  This gave me a set of guidelines organized by key areas (authentication, authorization ... etc.)
    6. right-clicked my view, chose Save View As ... and saved the doc to my desktop.

    This gave me a single Word document of the ASP.NET 2.0 security guidelines with an index up front and the details in the doc.  I repeated the steps to create a set of ASP.NET 2.0 security checklist items. 

    If necessary, I could have tailored the guidance before creating the document.  Another feature that's not well known is that you can use Guidance Explorer as an authoring tool.  You can quickly modify the content of guidance modules and then save to one of your read-write libraries.

     

  • J.D. Meier's Blog

    Security Influencers

    • 1 Comments

    IT Security posted their list of The 59 Top Influencers in IT Security.  They say their list includes "...most influential security experts of 2007 - from corporate tech officers and government security types, to white hat hackers and bloggers."  I don't get caught up in whether it's the right list or complete list.  Instead, I use the list to look for names that I don't recognize to see who might have new ideas or thoughts I should explore. 

    On the Microsoft side, I like to browse the following lists to see what our security-minded community is up to:

  • J.D. Meier's Blog

    Perspectives Frame

    • 1 Comments

    Building software involves a lot of communication.  Behind this communication, lies perspectives.  These perspectives often get lost somewhere between initial goals and final product, which can lead to failed software.  I found that by using a simple Perspectives Frame, I improve my chances for success.

    Perspectives Frame

    • Industry Perspective - industry constraints and standards
    • Business Perspective - business goals and constraints
    • Technical Perspective - technological requirements, technical standards and practices
    • User Perspective - User experiences and goals

    In Practice
    I could easily over-engineer it, but in meetings and hallways, this quick, memorable frame of four categories helps.  OK, so it looks simple enough, but how do I use it? Here's how I use it in practice:

    • Understanding goals - First things first, I want to know goals and drivers from the different perspectives.  Knowing which bucket they fall in, helps more than a random collection of requirements.
    • Understanding priorities - Which perspectives take precedence?  For example, corporate line of business applications tend to optimize around industry and business at the expense of the user experience, since users don't have much choice.  On the other hand, an emerging breed of social software applications, puts the user front and center.  In another case, e-commerce applications have to get the user experience right, since users do have choices.  
    • Checkpointing representation - Is my customer representing the user, business, technical or industry perspective?   Do I have the different perspectives represented?  
    • Rationalizing decisions - If I know that for a scenario, user experience take precedence, I can make more effective decisions, moving towards the goal.
    • Rationalizing feedback - If I know which perspective feedback is coming from, I can have a more meaningful prioritization discussion. If the team knows that for this case, the success of the user experience is key to the business success, that's a different story than if we 
    • Choosing the right techniques and tools - Some techniques tend to be optimized for a particular perspective.  That's a good thing.  The trick is to know that and explicitly decide if it's the right tool.  For example, performing Kano Analysis can help you identify user satisfiers and dissatisfiers.  On the other hand Taguchi methods will optimize around technical perspectives.

    This perspectives frame becomes even more powerful when you combine it with MUST vs. SHOULD vs. COULD and What Are You Optimizing.

  • J.D. Meier's Blog

    MUST vs. SHOULD vs. COULD

    • 6 Comments

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

    Here's an example of some scenarios and usage:

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

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

  • J.D. Meier's Blog

    Tag Big Buckets First

    • 1 Comments

    Here's an example of a mistake I made tagging to illustrate how I'm now thinking about tags.  I originally created the following three tags for my team system nuggets: Visual Studio 2005, Team System, and Team Foundation Server.  I did this because I first did my research on Visual Studio Team System tags and found that's what Technorati was using.  I figured by covering my bases, users would find what they might otherwise miss.

    The problem with this approach is I no longer had a single big bucket to show me all Visual Studio Team System posts.  This approach is also error prone (tag a post with two out of the three buckets).  Worse, I was cluttering my tag cloud, without adding value.

    I then adopted the approach of thinking in big buckets first.  For now, all my team system related posts will go into my Visual Studio Team System tag.  If I need to chunk that up, then I'll add a tag for my team foundation server posts.  If I need to further divide then I'll add tags for sub-buckets like source control, reporting, work items ... etc.  I'll also draw from my research on Visual Studio Team System tags

    I should point out that while now I think in terms of big buckets to small, I like the fact that I can also jump right to the smaller bucket.  However, I also know that I can count on one big bucket to contain all my smaller buckets.

  • J.D. Meier's Blog

    View-Driven Tagging

    • 1 Comments

    I'm not satisfied with the browsability of my blog.  While I can get to a lot of the nuggets I need, sometimes I have to dig.

    My initial reaction was that I just need to throw all my nuggets into a Wiki and do what I do best.  Then I realized, no, I'm making a very basic mistake.   True, blogs are oriented around time, but there's a lot I can do with tags.  I simply need to make the most out of what I've got, before I take another path.

    There's a few things I need to do:

    • Think in terms of drill-down.  I was thinking too much about multiple entry points and not enough about bigger buckets to smaller buckets. 
    • Think big-buckets first.  I need to think in big buckets first.  For example, I need to browse all the Security.  Within security, I then want to browse Security Engineering. Or within Performance, I then want to browse Performance Engineering. 
    • Test-drive my views.  It's one thing to tag, it's another to use them.  I sometimes get surprised when I click a tag and don't see the set of posts I expect.  I need to make browsing my tags more of a habbit.
    • Use under-the-gun tests.  It's one thing for me to find what I want, when I take my time.  Can I do it on the fly, can I do it fast, can I do it when I'm at somebody else's machine and I have 30 seconds to make a point?
    • Test with users.  OK, so I can find my posts and I can find them quickly.  Can my teammates or a customer?  Time to test.

    I do have a few other rules of thumb that guide me.  Rather than make a bunch of buckets up front and then wonder how to fill them, I prefer to make them as I need them.  Also, even though I'm adding a little more focus to being able to walk my categories, I realize there's many paths, and part of the power of tags is more about "related item" discoverability, than actual hiearchy.

  • J.D. Meier's Blog

    Driver's Guide vs. Owner's Manual

    • 3 Comments

    One of the metaphors I use to explain the distinction between documentation and guidance is Driver's guide vs. Owner's Manual.  While I could go into the finer details, it's a good starting point.  From an owner's manual, I expect to see how things work and how they're intended to be used.  From a driver's guide, I expect "how to get the most out of it."

    I see the two bodies of information as very complimentary.  I also see them as distinct.  I wouldn't want to mix my driver's guide with my owner's manual.  However, I do want to be able to seamlessly go from one to the other, when I need to.  I also want my owner's manual written by the people that built it and I want my driver's guide written by the people who use it in action.

    In practice, I use my owner's manual when I care and tune my RV.  When I take a cross country trip, I use my driver's guide.  Knowing this distinction helps me choose the right tool (information set) for the job, as well as set my expectations about the type of information I'll find.

    I think finding the right metaphors is important because it helps illustrate a distinction that's not always obvious or hard to explain.  I don't think guidance is yet a pervasive part of our technical landscape, and yet I see it as a key differentiator between success and failure.  By pervasive, I mean I can use any product or technology and easily find the driver's guide.  I mostly see owner's manuals.  

  • J.D. Meier's Blog

    Code Sharing in Team Foundation Server

    • 4 Comments

    How do you share code in Team Foundation Server?  That's what our team is working through at the moment.  We're looking at what's working, what's not working, and what should customers be doing.

    Here's how we're basically thinking about it so far:

    • There's two main code sharing paths: source and binary.
    • Within source code sharing, there's two approaches:  workspace mapping on the client and branching on the server.
    • The key issues are how to deal with parallel development and how to share across projects

    Here's what seems to be our emerging guidance:

    • If you're coding in parallel, and you need real-time updates, start with workspace mapping.
    • If you need periodic snapshots, or if you need isolation from the changes, then consider a branching approach.
    • If the source you need to reference is relatively stable, then consider using the binary.

    The problem with workspace mappings is that they're developer specific.  Each developer will need their own mapping.  You'll also need to lock down permissions to avoid accidental changes.  Branching has the advantage that you can be explicit about taking changes, so you have stable builds but with the overhead of merging.  You can branch within the same project or cross-project.  A separate project might make sense if you have multiple projects consuming the code.

    I need to still look across more customer sets, but so far I mostly see binary reuse.

    I'm particularly curious in any lessons or insights those of you would like to share.  I think this is an important area for effective source control practices.

  • J.D. Meier's Blog

    Progressive Development Blog

    • 1 Comments
    How do you turn around your software development practices?  Well, follow along in the adventures of Maven and Motley in the Progressive Development Blog.  While the stories are fiction, they're based on practical experience and learnings by a member of our Development Excellence Team at Microsoft.  I look forward to the weekly posts.
  • J.D. Meier's Blog

    Thinking About Career Paths

    • 2 Comments

    I'd like to share some of the insights that others have shared with me over the years about choosing paths.  My favorite insights have always been guiding questions that help me choose my own adventure.

    Mentor #1

    • Do you want more fame, fortune, time, or love?
    • Do you want to be a thought leader or a people leader?

    Mentor #2

    • What are you doing that you currently enjoy?
    • What do you want to do more of each day?
    • What do you want to do less of each day?

    Mentor #3

    • What problems are you working on?
    • Who are you working with?
    • What impact are you making?

    As more folks ask me about their careers, I've found myself talking about three things  

    1. Your network helps you.  It's a small world.  Don't burn bridges.  The best networkers I know, balance their weaknesses through strengths in others.
    2. Your career is a portfolio of experiences.  What do you want under your belt?  A twist on this is, what are the unique experiences you can have, where you are right now?  For example, what sort of things can I do at Microsoft that I wouldn't do anywhere else and how do I make the most of it?
    3. Your approach sustains you.  Knowledge is very transient.  It's how you learn and how you adapt that carries you forward.
  • J.D. Meier's Blog

    Meeting with Anil

    • 1 Comments

    I met with Anil John today since he's in town for the 2007 MVP Global Summit.  I always like talking with Anil because he asks the tough questions, he has thoughtful feedback and he keeps things real.

    Anil's first question for me was why are there three different threat modeling approaches (SWI, ACE, and patterns & practices).  This was easy for me since, I used to get asked this fairly regularly.  Rather than focus on the implementation deltas, I focused on the context that shaped them.  SWI threat modeling was born among our Microsoft product teams.  ACE threat modeling was born among our internal line of business applications.  patterns & practices threat modeling was born among an external set of customers, dominantly corporate line of business applications and vetted by some agile practitioners.  They all work, so the trick is to  figure out which one fits your scenario best.

    Next, I shared my secrets for project management and personal effectiveness.  It was nice to be able to finally walk Anil through some real examples and use the whiteboard as needed.  Some concepts are easier to show and tell, then they are to write about in a way that sticks. (that doesn't keep me from trying!)

    Over lunch, we reflected on career paths and stories.  One point that really hit home was how small the world really is.  We both noted that throughout our paths, there's always been a set of people that tend to show up time and again.  One more reminder, not to burn bridges!

  • J.D. Meier's Blog

    3 Tips for Branching in Team Foundation Server

    • 2 Comments

    One of my readers asked me if I could provide a bit more insight on branching.  I think the best thing I can do here is summarize a few tips and then point to some useful resources.

    Key Tips

    1. Don't branch unless you need to.  You can always label a release build and branch later.  Use branching for isolation while doing parallel development.
    2. Know the common branching patterns.  These include branch by feature, branch by release, and branch by team.
    3. Use a common folder structure for your branches.  While your branching can be organic and evolve over time, a thoughtful folder structure can help. 

    Here's an example starting point.

    /Main
    	/Source
    	/Build
    	/Docs
    	/Scripts
    	/TestCases
    /Development
    	/FeatureBranch1
    	/FeatureBranch2
    /Maintenance
    	/Release 1
    	/Release 1.1
    	/Release 1.2
    

    In this case, Main is your main source tree and project assets.  Development is a root level folder for isolating your features or teams (branched off your Source folder in Main).

    More Information

Page 39 of 44 (1,086 items) «3738394041»