J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • 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

  • J.D. Meier's Blog

    Meeting with Rudy

    • 1 Comments

    I got some face time with Rudy Araujo today.   I always enjoy our meetings because we talk about anything from security to personal productivity to future software trends.

    Today, we bounced around topics including compliance, agile, systemic problems, software scenarios, security guidance for business, mash ups, virtualization,  blogging practices, password management, MindMaps, and managing action.

    The highlight for me was that Rudy shared my belief that businesses need more help rationalizing how to bring security into the picture.  While there's a lot of technical guidance available, there's simply not enough prescriptive guidance for the business stack.  I've talked to analysts and customers about incrementally adopting security, but I think it's time to make that information more broadly available.

  • J.D. Meier's Blog

    Multiple Solutions and Flat Projects

    • 1 Comments

    Graham Barry, one of the key VSTS members helping us pave our paths through Team Foundation Server, shared a model he likes to use.  He uses multiple solutions, but with a flat project list:

    /Source
    	/WinFormsProject
    	/WebProject
    	/WindowsServiceProject
    	/ClassLibrary1
    	/ClassLibrary2
    	/ClassLibrary3
    	Web.sln
    	Service.sln
    	All.sln
    

    It's flat, but effective.  You get flexibility and you avoid baking in a folder structure than can be tough to change.  You can also spin up solution files for presenting different working groups of the projects as you need them.

  • J.D. Meier's Blog

    Structuring Projects for Team Foundation Server

    • 14 Comments

    I've seen a few customers asking how to structure projects for Team Foundation Server.  I don't blame them.  Finding a structure that works well for you can be tricky, particularly if you don't have the benefit of hind-sight or a bunch of reference examples to draw from.

    My team spent some time this past week evaluating various approaches and lessons learned from various projects  We boiled it down to something that seems to be working well, and distills what's worked for some teams.  With the caveat that we're still evaluating, here's what we learned ...

    Solution
    Local File System

    C:\MyApp
    	\MyApp.sln
    	\Source
    		\MyAppWeb
    		\ClassLibrary1
    


    Source Control (Team Foundation Server)

    /Main
    	/Build
    	/Docs
    	/Source
    		/MyApp
    			MyApp.sln
    			/Source
    				/MyAppWeb
    				/ClassLibrary1
    			/UnitTests
    				/MyAppWebTests
    				/ClassLibrary1Tests
    	/Tests
    


    Key points
    Here's a few highlights about this approach:

    • On the client side, we explicitly creat our solution file up front instead of rely on defaults
    • The project folder containts one master solution. 
    • The project has source and unit tests.  Loading the solution for the project, loads the source and unit tests
    • The Main folder in TFS holds the project assets (Build, Docs, Source, Tests).  Using Main lets us create other folders for potential branches (Development, Production, Maintenance ... etc.)

    Repro Steps
    Here's a brief walkthrough to test using a file-based Web:

    1. Create a blank solution in VSTS
    2. Create a source folder on the file system (C:\MyApp\Source)
    3. Add new Web project (C:\MyApp\Source\MyAppWeb)
    4. Add new Class Library (C:\MyApp\Source\ClassLibrary1)


    Verify your folder structure on your File System:

    C:\MyApp
    	\MyApp.sln
    	\Source
    		\MyAppWeb
    		\ClassLibrary1
    


    Adding to TFS

    1. Add your solution to source control
    2. Create a Main folder
    3. Create a Source folder beneath Main

    Verify your folder structure in Source Control Explorer

    /Main
    	/Source
    		/MyApp
    			/MyApp.sln
    			/Source
    				/MyAppWeb
    				/ClassLibrary1
    

    More Information
    You should know that while I talked through the single solution scenario, there are additional patterns.  Here's the key patterns we see:

    1. Single solution
    2. Partitioned single solution
    3. Multi-solution

    You can find more on these patterns at Team Development with Visual Studio .NET and Visual SourceSafe.  You should also know that we have a few How Tos on structuring your projects coming your way.  We'll post them to our VSTS Guidance Project.

    Share Your Story
    If you've got lessons learned the hard way or practices to share, I'd like to hear them.   Now's a great time to share since we're actively building guidance.  Either comment here or write a post and leave a link. 

  • J.D. Meier's Blog

    Web 2.0 ... The Machine is Us/ing Us

    • 1 Comments

    Web 2.0 means a lot of things to different people.  For me, it means moving from a read-only, one-way Web  to a read-write, conversational Web.  I think the most exciting part is the shift from sites serving content to humans driving the experience.  The machine is us!  Where will we take us next?

    For a short, thought-provoking video, watch Web 2.0 ... The Machine is Us/ing Us.

  • J.D. Meier's Blog

    Roles and Goals

    • 1 Comments

    The next time I need to get a set of requirements, I'm simply going to start with roles with goals.

    I made the mistake of asking for a set of scenarios.  What I ended up with is a list of user tasks.  Tasks aren't the same as goals.  Flying a kite is not the same as having a goal to discover electricity.  One is what you're doing, the other is what you want to accomplish.

    Since I didn't have the benefit of direct customer interaction for this case, I'm using that as a challenge.  What is the most precise, reliable way to get the information need?  Roles with goals.  I realized, iterating on a list of roles with goals, would get me closer, faster.  I can always drill into the stories or scenarios from the goals.  The reverse doesn't seem to be true.

  • J.D. Meier's Blog

    David Anderson's Recipe for Success

    • 1 Comments

    David Anderson distills his software management learnings down into four bullets:

    • Focus on Quality
    • Reduce Work-in-progress
    • Balance capacity against demand
    • Prioritize

    He names this set a recipe for sucess.  Here's what the recipe mean to me.

    Focus on Quality.  For me, focusing on quality means pushing quality upstream, and choosing quality over scope or quantity.  It also means quality isn't somebody else's job. 

    Reduce work-in-progress.  Reduce work-in-progress really hits home. Carrying too much in-flight work leads to excessive task-switching and administrative overhead.  In the buffet of work to be done, frequent small plates, wins over the single, large plate that over-floweth.       

    Balance capacity against demand.  Thinking in terms of demand, helps me right-size execution.  Specifically, it helps me think in terms of frequency (how often do I need to deliver value), size (how big does the value need to be), and quality (what does good enough look like now versus perfect down the road).  

    Prioritize.  There's always more work than we can possibly do.  To prioritize problems, I think about pervasiveness and impact.  Sometimes I need to prioritize a lesser problem that hits  more people, over a bigger problem that hits few.  I also keep my teams focused on value delivered vs. work completed.  It's a subtle shift in mindset, but it makes all the difference.

    More Information

  • J.D. Meier's Blog

    Making 30 Day Improvement Sprints More Effective

    • 7 Comments

    In my 30 Day Improvement Sprints post, a reader asked, what tips do I have to make 30 days sprints more effective.  Here's my short list

    • Buddy up.  Seriously.  One guy's hurdle, is another girl's breeze.
    • Don't beat yourself up.  If at first you don't succeed, tell yourself you just learned another way how NOT to do something.
    • Count your improvements, not your blunders.  It's a pick you up vs. put you down approach.
    • Make each session count.  Keep your sessions short and sweet.   Slow and steady wins the race.
    • Focus on your improvement process vs. the result itself.  Make the process your reward.  I enjoy learning again for learning's sake.       
    • If you're churning, change your approach.  Don't mistake churn for awkwardness. Growth feels awkward and is a precursor to proficiency. 
    • Find experts you can model and learn from.  Success leaves clues.  If you can find somebody who does a great job at what you want to do, you have a head start.  I leverage lots of mentors.  I used to just see an amazing pool of people around me.  Now I see an amazing team of coaches.
    • Journal your lessons learned.  Each day, reflect on distinctions you made.  What's one little thing you learned you didn't know the day before.  You'll be surprised how simple notes can shine a spotlight on your gains.
    • Repetition is your friend.  Remind yourself that repetition is the mother of skill.  World class experts master the fundamentals through repetition and refinement.
    • Set your own bar vs. follow others.  Don't compare yourself to others; compare yourself to you.  Be your personal best.  I remember a point John Wooden made some time ago.  He didn't think his team should gloat over wins, or beat themselves up over losses.  His point was, if you won, but didn't play your best, did you really deserve to win? ...  If you lost, but you played your personal best, did you really lose?
    • Focus on the thinking, feeling and doing.  Sometimes the inner dialogue is more important than what you see or hear.  While something might seem purely physical, sometimes, there's a lot of self-talk an expert does that might not be obvious.  What do they think about when they perform the technique?  When they mess up, how do they get back in the zone?  What's their decision tree?  For example, when I do a customer arch and design review, they see me put stuff on a whiteboard.  They hear me ask precise questions.  What they might not know is the matrix of questions and reference examples I draw from.
    • Be your own best coach.  Use questions to shape your improvement.    
    • Ask for feedback.  Find those you trust to point out things you might otherwise miss.  

    Few problems withstand sustained focus.  There's a bit of captive genius in everyone that just needs to be uncorked.  30 days of focused improvement seems to be a great way to pop the cork.  I'm finding improvement sprints refreshing because I now have a schedule for exploration.  I can rotate through more interests.  Most importantly, rather than tackle everything all at once, I just wait for my next 30 day focus.  It's easier to put something aside for the moment, if I know I'll have a chance to immerse myself in it in the future.  If I enjoyed something so much and I want to continue, I just do another 30 days.

    Hope that helps!

    Related Posts

  • J.D. Meier's Blog

    Requirements Perspectives

    • 3 Comments

    Here's a simple set of perspectives I use for rationalizing requirements:

    • User
    • Business
    • Expert / Technical
    • Industry/Standards

    Believe it or not, simply identifying these perspective helps a lot.  You'd be surprised how many debates happen simply because nobody explicitly identified the source or perspective of the requirement.  You'd also be surprised how quickly this helps you make more deliberate decisions and understand what you trade. 

    How does this help?  Your business goals might be a n orders per hour.  Meanwhile, your user wants sub-second response time.  Well, that's what your users want, but what will they tolerate?  Can your business afford the resources for an idealistic experience?  Design is always about trade-offs.

    In practice, I generally see industry/standards trump business trump expert/technical, trump user.  Unfortunately, a lot of software has unconsciously catered to the expert/tech/business at the expense of it's users -- making a lousy experience.  On the flip side, some software has catered to users at the expense of the business or industry goals.   See the dilema? 

    You can make a difference.  If you build software, know the perspectives, know the goals, and know the scenarios.  In some contexts, some tech/expert reccomendations simply do not make sense.  Know what you're optimizing.  In some scenarios, industry/standards reign, while in others user experience is king.  Make sure you have the right representation at the table.  Don't ask your patient to prescribe the medicine, or your doctor to rate the taste.

  • 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

    Prashant Bansode is Blogging

    • 1 Comments

    Prashant Bansode has stepped up to the blogging plate.  He's been a core member of my team for a few years.  I first met Prashant, when he reviewed our Improving .NET Performance and Scalability.   I was impressed by his attention to detail, focus on the customer, and keeping things real.  Next, we teamed up on .NET 2.0 Securirty Guidance, exploring new models for more consumable guidance.  During this adventure, I found that Prashant was a developer who could do it and write about it -- a trait I value.  Our next adventure was Guidance Explorer -- an R&D experiment around building tooling to help change the guidance game.  We learned a lot about innovation, distributed teams, scenario-driven engineering, and shipping software incrementally and iteratively.   Our latest adventures include learning how to build guidance projects on CodePlex:  Performance Testing Guidance and Visual Studio Team System Guidance.

    Prashant has worn many hats throughout our adventures together -- developer, tester, writer, mentor  ... you name it.  He's a true case of student becomes the teacher.  Be sure to stop by and say Hi to Prashant at his new blog:  PAB's World  (Prashant uses his initials).

  • J.D. Meier's Blog

    Influencing Without Authority

    • 2 Comments

    Today I got some relevant training for today's world - how to succeed when you don't have authority and control over execution.  This is a common scenario in cross-team, cross-group scenarios.  At Microsoft, you don't get rewarded by saying, "...if only I had control over authority and execution ... I would be successful."

    At the heart of the class was the model of influence without authority:

    1. assume all potential allies
    2. clarify goals and priorities
    3. diagnose the allies world
    4. identify relevanc currencies
    5. deal with relationships
    6. influence through give and take

    You obviously deal with relationships throughout the process.  If you assume those you need to influence are allies, you're in a more resourceful state.  If you don't clarify goals or understand the world of those you influence, then you can miss out on finding mutual purpose or understanding why or where you get stuck.  Currency is more than money; it's any type of exchangable value, such as expertise, resources, ... etc.    

    I liked the class.  The ideas weren't brand new, but instead of sit back and think, it was roll up our sleeves and apply the tools.

  • J.D. Meier's Blog

    Ward and the Wiki Way

    • 1 Comments

    When Ward Cunningham was on our team, I learned a lot about building Wikis.  He walked me through my first Wiki page.  He probably didn't expect that 4 days later, I'd have more than 500 Wiki pages (he added a counter to my wiki!) 

    Ward told me Wiki Wiki was Hawaiin for fast, and he wanted to simplify publishing (the writeable web). This explained away my initial complaints of formatting and features, and I adopted the mindset of shapable content you can evolve over time.  I thought of Wikis as notepad for the Web.

    Ward and I had a lot of insightful conversations around various Wiki issues: one Wiki vs. many, choosing namespaces, choosing names, collaboration ... etc.  The most important lesson for me was to think in terms of great pages.  This meant, choosing better page names and make pages that matter.  How to eat an elephant? ... one bite at a time.  How to build a useful Wiki? ... one page at a time.

  • J.D. Meier's Blog

    30 Days of Living Foods Ends Today

    • 4 Comments

    Today ends my 30 day experiment eating living foods.  I'm a burger and pizza boy at heart, so this was a big change.  Friends and family noticed my slimmer look and healthy glow.  A friend of mine said I found the Fountain of Youth.

    Here's what I noticed:

    • dropped 12 pounds
    • had enough energy to start working out again
    • shed my skin
    • eliminated sinus issues I had for a life time
    • stayed healthy while others got sick
    • maintained peak performance throughout my days
    • got the eye of the tiger back

    I didn't expect to shed my skin so that surprised me, but I liked what was underneath.  I was also surprised by how some issues were dietary vs. natural.  Nature vs. nurture strikes again! 

    Friends asked me what practices I'll carry forward:

    • more water over soda
    • balance my bad foods with more good foods (I'll eat my veggies - Mom will be proud)
    • raw vegetables over cooked
    • stick with my workouts (again to balance my bad foods)
    • more frequent meals

    Most importantly, I learned how to effectively do living foods for 30 days.  This means, I can choose to do 30 day tune ups throughout the year.  What I walk away with is a better idea of how foods affect me, how to balance my bad foods with good, and how to tune my body when I get run down (or need to fend the flu season).

    We're such thinking, feeling, doing creatures at heart and food has such a big impact on the way we think and feel.  I'm going to explore more options.  A friend of mine suggested testing intuitive eating, where you eat what your body craves, not what you mind thinks it wants.

  • J.D. Meier's Blog

    Deep Enterprise 2.0 Penetration

    • 1 Comments

    In Now THAT's What I'm Talking About! , Andrew McAfee writes about a case study of deep Enterprise 2.0 penetration:

    "Highly popular, and highly useful.  I find that the sites I visit most often these days are ones that give me 'the latest.'  They help me stay on top of (or at least feel like I'm staying on top of) the world, the blogosphere, and my personal network of people and content.  This page does the same thing at the company level for AARF employees.  It gives them 'the latest' about their work environment.  And it does so in a bottom-up and egalitarian fashion.  This page doesn't contain the latest information that the company's senior managers, or its IT staffers, think employees should know about; it contains the latest information that employees think employees should know about."

  • J.D. Meier's Blog

    MVPs for Team System

    • 1 Comments

    I updated our index of Team System MVPs index today so that my guidance team can quickly see the profiles and blogs.  I couldn't find some blogs, but I'll add them as I find them over time. 

  • J.D. Meier's Blog

    Enterprise 2.0

    • 1 Comments

    I like how Most Business Tech Pros Wary About Web 2.0 Tools In Business summarizes a Web 2.0 +  Enterprise world ...

    "Enterprise 2.0 can't just be about a wiki here, a blog there forever. Taken together, the emergence and convergence of Web 2.0 and IP communications is what will determine whether there's truly an Enterprise 2.0. It's a new architecture defined by easier, faster, and contextual organization of and access to information, expertise, and business contacts--whether co-workers, partners, or customers. And all with a degree of personalization sprinkled in."

  • J.D. Meier's Blog

    Guidance 2.0

    • 3 Comments

    Imagine what a Guidance 2.0 world might be like ...

    • browse tag clouds of reusable "architecture nuggets"
    • subscribe to "guidance feeds" that give you the latest practices and recommendations
    • share your "guidance" playlists with friends (share your favorite collections of how tos, guidelines, checklists)
    • build guidance mashups from your favorite trusted sources of information
    • rate the guidance and rate the raters (think Amazon or EBay)
    • browse a federation of guidance Wikis in your company and in the community

    I think next-gen guidance is about bringing together a lot of key concepts:

    • context-precision (using context to organize information)
    • personalization (create your own views, tailor it for your needs, ... etc.)
    • community type ratings (expose the thinking and rate the raters for the guidance)
    • guidance types (evolvable schemas for guidance types, such as how tos, guidelines, checklists, patterns ...)
    • Folksonomy over taxonomy

    A lot of today's guidance lives in blogs.  Part of the problem (and beauty) of blogs is that every end node is a blob of information.  What if there were RSS end nodes that contained "collections" or "lists" of how tos, guidelines, patterns ... etc.?  From a very practical standpoint, I would love to subscribe to the latest MS (or any company) recommendations and view those in a type of my choice (patterns, guidelines, how tos ... etc.)  The mashupability is endless.

    Those are the ideas that drove and shaped Guidance Explorer.  Guidance Explorer was just one small step towards a world of more effective and efficient guidance.

  • J.D. Meier's Blog

    patterns and practices Visual Studio Team System Guidance Now Available

    • 6 Comments

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

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

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

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

Page 38 of 42 (1,043 items) «3637383940»