Tuesday, December 16, 2008

Application Architecture Guide is Available

After many months of work, we've released the patterns & practices Application Architecture Guide - http://www.codeplex.com/AppArchGuide.  You can download the pdf or you can view it all on the web, whichever is easier for you.

This is a 381 page playbook to designing well architected applications on the Microsoft .NET platform. It covers web applications, mobile applications, rich client applications, services and rich internet applications (like Silverlight). The guide is a distillation of many lessons learned from architecture experts both internal and external to Microsoft.  It’s principle-based and pattern-oriented to provide a durable, evolvable backdrop for application architecture that you can use for many years to come. 

Some key features of the guide:

  • Canonical app frame - Describes at a meta-level, the tiers and layers that an architect should consider. Each tier and layer is described in terms of its focus, function, capabilities, common design patterns and technologies.
  • App Types - Canonical application archetypes (such as web application or rich client application) are used to illustrate common application types.  Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains.
  • Arch Frame - A common set of categories for hot spots for key engineering decisions. These include categories such as authentication and authorization, caching, state management, composition, configuration, transactions, validation, workflow and more.
  • Quality Attributes - A set of quality attributes that shape your application architecture, such as performance, security, scalability, manageability, reliability and more.
  • Principles, patterns and practices - Using the frames as backdrops, the guide overlays relevant principles, patterns, and practices, such as model view controller pattern, data transfer objects, service gateway, facade and more.
  • Technologies and capabilities - A description of the Microsoft platform and all the relevant technologies. For instance we provide guidance about which data access technologies to use, which UI and presentation layer technologies are best suited for your scenario, and when to use WCF vs. ASMX.

If you are an architect or a developer on the .NET platform, I highly recommend you pick it up. Its free, so you have nothing to lose!

Friday, December 12, 2008

How to Get Results

Inspired by the Zen of Results E-Book, the members of my team had a spirited discussion on personal productivity. The book contains great information but it didn't address a burning question on the mind of one of my team-mates:

Interesting --- but I think it's overly simplistic and misses the hard stuff.

To me the challenge is really: how to best manage the inevitable disruptions to my plans?
How do I balance working towards the objective against the immediacy of a 'crisis' -- and not just
poor planning on my part. I'm not abrogating my responsibilities, but I'm unwilling to accept that
failure to achieve an outcome is a negative. Is that excuse making?

I think the key insight from the Zen of Results is that you need to free yourself from your tasks, free yourself so you can focus all of your energy on the creation and delivery of real value.  I've seen many people create tasks with some goal in mind (the value) and then stick to those tasks through hell and high-water without realizing that the completion of the tasks is no longer leading them to the goal. I really like the workkflow in the Zen of Results because it reminds you to think about each week as a way of creating and delivering value and reminds you to reflect on your results each week to see how you can improve.

Here are the techniques I use to help me focus on results and avoid falling in the trap of becoming overly attached to my backlog of tasks:

  • I keep a list of my strategic goals in Evernote. These are my large, long-term objectives that may span many months or even years.  I use these to remember what my big targets are.
  • Every Monday I build a list of the outcomes I want to achieve for the week. These map to the strategic goals and are usually sub-goals that are achievable within a week's time.
  • Every day I create a list of tasks I want to accomplish. These are short-term activities that I can accomplish within the next 48 hours. As I finish the tasks I delete them and then replenish them the next day.
  • Every Friday I review the results I achieved and reflect on how they differ from what I set out to accomplish for the week.

When I, or my team, misses a planned outcome I do some investigation to figure out why. I don't look at the missed result as a failure, but rather an opportunity to improve planning and thinking for the future.  I've found missed outcomes are usually caused by one of the following:

  • I misjudged scope and got less done than I hoped for.
  • I was surprised by a new priority that I hadn’t planned for.
  • The planned outcome was wrong and I needed to adjust mid-week.

If I understand the 'why' then I can plan more effectively in following weeks. Its important to remember that things don’t always go according to plan – you have to plan for that too. Outcomes are your target, like any marksman you will not always hit them 100%.

This led to a new question from the team:

I guess I'm balancing the incremental steps required to achieve a major objective (like iterations building to a release) with the 'crisis du jour' syndrome that can overwhelm. Sometimes (not often) there are more
unplanned activities than planned ones -- endangering the critical goals for sure!

so -- say you've had 2 weeks where you accomplish nothing that has meaning to you --
not one of your objectives -- what's your trick for trying again?

I think in a situation like that you need to first ask yourself what happened.  Were your planned outcomes interrupted by new outcomes that were truly of higher priority?  In other words did you sacrifice two weeks but in the end it added more value than if you had stuck to your planned outcomes? If so, it was the right choice.  On the other hand, it could have felt necessary but still wasn’t worth it – we get trapped in these kinds of binds from time to time due to randomization, poorly planned objectives, fuzzy priorities, etc.  Or it could be the work needs to be done but it should be done in parallel and you aren’t the right owner – delegate!

This is how I think about it:

  • Reprioritize
  • Delegate
  • Defer

Reprioritization works if you really need to drop everything and the new work is critical path.  Delegation works if it is important but can be done in parallel by someone else.  Deferring the work is a good fit if the crisis is not really a crisis and it can be set aside to cool down. I found many times a crisis isn’t as big of an emergency as it seems and it can be slotted into the work queue to be deferred till later.  If there is an ongoing stream of unplanned crisis that continue to take top priority, thereby pushing back other important work, then there isn’t much point in planning, right? You need to understand root cause and attack that first so that the environment is conducive to planning again and is no longer anarchy and chaos. This is similar to the change frame I wrote about in an earlier post

Prioritization is critically important to make sure you are focused on the right tasks each day. Focusing on outcomes is a good technique, but there were a few other techniques discussed, for instance:

If too many things are “ultra high priority” I have a hard time prioritizing the things at the top of my list. When this happens I find that it becomes even more important for me to feel like I’m making progress, or I can spiral into a pit of despair. When this happens the best thing to do is to select something from your high-pri list that you know you can really sink your teeth into quickly. As they say, even the longest journeys begin with a single step, don’t focus on the how far away the destination is, focus on the steps.


Another technique I use is to walk away from my computer alone, or close my eyes, for 5 min. This gives me just enough time for the really urgent stuff to rise to the top, and the other stuff to fall away. It’s a short enough time that I can convince myself to do it, without feeling guilty for doing something else.


Once I’m back down to a manageable list of tasks I prioritize again, and group small tasks together in 30-60 min blocks, then prioritize those as one unit. I find that if I don’t group small tasks together that they’ll fall off my radar and won’t get done. This also reduces context switching which can be a killer.


At this point I have my über-list of tasks that need to get done, in the morning I look at my list, reprioritize, and take my first step.

Key Insights

  • Focus on outcomes first, tasks second.
  • Understand how what you are doing will help you or your team create and deliver value.
  • Create a workflow that will help you stay focused on delivering value.
  • If you are having trouble hitting your goals, understand why and then use a technique to improve your results - don't spiral into the pit of despair.
  • Results build upon results - if you are losing effectiveness, find something you know you can sink your teeth into and get results quickly. Build on that momentum.

My Related Posts

Wednesday, July 30, 2008

Improving Web Services Security Guide is Available

In an earlier post I wrote about the experience of working with Microsoft on a guide to help teams use Visual Studio Team System more effectively.

I'm happy to announce that we recently completed a new guide - Improving Web Services Security. The goal for this guide was to collect best practices and guidance to help architects and developers create more secure Windows Communication Foundation (WCF) applications. Much of the guidance is also generally applicable to any Web Service development project, so if you are focused in that area its worth checking out.

You can download the guide here:
http://www.codeplex.com/WCFSecurityGuide

Monday, July 28, 2008

The Change Frame

Do you ever find yourself in a situation you don't like? Most of us find ourselves in difficult situations in our professional or personal lives from time to time.

In a tough situation you can adapt yourself to the situation, adjust the situation, or avoid the situation entirely. This 'change' frame is a great way to think about how to handle difficult situations when they occur.

  • Adapt. Adapt yourself to the situation by changing your approach or your mindset. If you are in a situation you cannot change but don't want to leave then this is your best choice.


  • Adjust. Adjust the situation to better suit you. Many times an intractable situation can be adjusted to become more bearable. If you are in a tough situation which would require you intolerable adaptation to make right and you see that there is a possibility of adjustment then this is your best choice.


  • Avoid. Sometimes the best choice is to run away. If the situation is intolerable, you cannot adapt to it, and you see no possibility of adjustment then this is your best choice.


  • Here is an example to make it more real:

    Imagine a work situation in which your manager gives you incomplete or vague direction. When you follow this direction you often end up getting criticism that you completed the task incorrectly. As a result you end up repeating work in what feels like a wasteful cycle. You may feel that your manager is mistreating you and that you cannot succeed in the situation.

    Here is how you could apply the 'change' frame:

  • Adapt. Change your work habits to ask for feedback more often so you can correct your course quickly and have more confidence in your work. Change your mindset to see the situation as an opportunity to learn how to be more effective at working with uncertainty.


  • Adjust. Speak with your manager and explain your need for more specific direction. Provide positive feedback to your manager when he provides you with the specifics you are looking for.


  • Avoid. Look for another job.


  • I think most people have a tendency to fall into one of these strategies by default. Some people tend to avoid too often, depriving themselves of opportunity. Others tend to adapt too easily, bending themselves when the situation should be changed instead. Others tend toward rigidity and will work hard to adjust a situation when a small adaptation on their part would have accomplished more.

    I tend to adapt more often than I probably should. What do you do?

    Special thanks to JD for teaching me the 'change' frame and blogging about it first.

    Thursday, July 10, 2008

    What Makes an Achiever?

    J.D. Meier asked me:
    Do you see a pattern where some are “achievers” and some are not?
    Achievers tend to produce, but just need coaching.
    Some people (Non-achievers or whatever to call them), seem to need more than coaching -- it’s more like a bad fit for a job that produces results along the way.

    That got me to thinking:
    1. How can you tell when hiring someone that they will achieve the results you are looking for?
    2. How can you tell when someone on your team is worth investing in and when you need to look for a replacement?
    When interviewing I test for aptitude, attitude, knowledge and experience and I usually hire with pretty good results. There are times, however, when someone will slip through that interviewed very well but doesn't do well on the job. My conversation with JD reminded me of this problem and got me to thinking about what I could do to improve my interview 'hit' rate.

    I think the best indicator of an achiever is where they focus their energy. Do they focus on process? Do they focus on theory? Or do they focus on results. If they don't focus on results they will not ever get those results. You get what you focus on. A lot of it has to do with how you are wired - what makes you excited? Some people truly get excited over theory. They make good scientists. Others get excited about results. They make good engineers!

    What is Your Management Style?

    I recently conducted an interview for a highly capable developer. I was the last person in the interview loop and I already knew I wanted to hire him, so I opened the time up to allow him to ask me as many questions as he wanted. Normally this translates into a few easy to answer questions. In this case I was asked a bunch that really made me think.

    One of the more interesting questions was - "What is your management style?"

    There are so many ways to answer this that at first I was stumped. Does my style even have a name? Should I talk about examples of what I've done to manage my team or talk more abstractly? In the end this is what I said and I think it rings true as a good, though not necessarily complete, answer:

    1. I believe in treating people like professionals. From the start I believe in giving and expecting trust. You don’t have to earn trust when you join the team. You receive it automatically and keep it unless you do something to lose it.
    2. I believe in delegating responsibility and authority. I want to give each person the chance to grown and reach for the stars, not be hobbled by low expectations or some ceiling I’ve put into place.
    3. I believe in personal accountability. If you make a mistake, own up, learn and move on.
    4. I believe in making mistakes. No one should be afraid to make a mistake. If you are going to fail, then fail fast.
    5. I believe in results. I measure people on results not activity. Activity without impact is poison to me.
    6. I believe in building a team. Each member of the team should be clear on their role, know where they fit in and feel they can depend on and lean upon others in the team to achieve group goals.
    7. I believe in adapting my management style to the needs of the employee. Some people need a very directive approach, some just need goals and the freedom to achieve them.
    8. I believe in real-time feedback. If you do something wrong you should know it immediately. If you do something right, you should hear about it right away. The further removed feedback is in time, the less effective it is.
    9. I believe in continuous improvement. On a daily and weekly basis we look at what went right, what went wrong, what needs to be tuned to improve effectiveness.
    When I was done talking I realized that I was the wrong person to ask. The best way to understand my management style is to ask my team - not me!

    My Related Posts