Software Engineering, Project Management, and Effectiveness
I created a simple map of the patterns & practices catalog of assets ordered by year. It’s both a quick walk down memory lane, as well as a way to take a look from the balcony. When I look from the balcony, I can see how our investments changed over time, how our catalog morphed, and the durability and sustainability of some of our asset types.
I was looking for some of my old job descriptions for PM positions in patterns & practices to help out a colleague. While I didn’t find them, I did find some of the questions that I have used to evaluate PM effectiveness:
Project Management
People/Team
Technical Expertise
Customer Focus
Communication
Microsoft
Serena Yeoh just released her Layer Architecture Sample for .NET 4.0 (July 2010), which targets the .NET Framework 4.0. Serena is one of our MCS (Microsoft Consultant Services) consultants in the field working with customers on a regular basis, and she was a key contributor of our Microsoft patterns & practices Application Architecture Guide.
Here is a description of the project according to Serena: The Layered Architecture Sample is designed to demonstrate how to apply various .NET Technologies such as Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), Windows Form, ASP.NET and ADO.NET Entity Framework to the Layered Architecture Design Pattern. It is aimed at illustrating how code of similar responsibilities can be factored into multiple logical layers which are applicable in most of today's enterprise applications. The primary objective of the sample is to focus on layering and therefore, certain cross-cutting functionalities have been omitted to maintain its simplicity.
What’s New for This Version of the Sample
Key Links
I’ll be curious to hear three things you like about it and three things you would improve?
As part of our Azure Security Guidance project, we tested setting up SSL during our exploration. To do so, we created a self-signed certificate and deployed it to Azure. This is a snapshot of the rough steps we used:
Step 1 - Create and Install a test certificate
makecert -r -pe -n "CN=AzureSSL" -sky 1 "azuressl.cer" -sv "azuressl.pvk" -ss My
pvk2pfx -pvk "azuressl.pvk" -spc "azuressl.cer" -pfx "azuressl.pfx" -pi password1
Note - You can find an explanation of the command line arguments for makecert.exe and pvk2pfx.exe on MSDN.
Step 2 - Create a Visual Studio project
Step 3 - Upload the certificate to Windows Azure Management portal
Step 4 - Publish the project to Windows Azure
Step 5 - Test the SSL
Your results may vary here based on your browser, but you'll most likely see a warning about the certificate being for a different site, or not being from a trusted source. If you permit access to the site, the page will render empty and you browser should indicate that the page was delivered over SSL with a lock icon or something similar.
My Related Posts
There are so many ways I can share how we do what we do on our Microsoft patterns & practices team, but I think the simplest approach is to share the values, guiding principles, and practices. When our group changed leaders, one of the first things our new leader did was build consensus around what patterns & practices was all about. I suggested using the values, principles, and practices frame because I thought it was a proven model. It sets up the framework and the context in which we operate, which in turn, guides everything else. Here’s the result:
Values In patterns & practices we value:
Guiding Principles We use the following principles to guide our work:
Execution Processes, Practices, and Tools
The beauty of patterns is that the insight is timeless. I was flipping back through a post on Architecture, Mobiles, and Health: 10 Pitfalls, by Eduardo Jezierski. Ed is a friend and we worked together for years, first in Microsoft Developer Support, and then in Microsoft patterns & practices. When Ed shares what's on his mind, he has an uncanny ability to put into word things that you have bumped into or know to be true, or a new lens that you need to look through.
This post is a roundup where I cherry pick my favorite points from his post on his lessons learned. Many of the points especially resonate because we they ecapsulate and magnify points we learned over time in patterns & practices, as we focused on architecture, viewpoints, scenarios, context, principles, patterns, and antipatterns.
Key Take Aways on Architectural Approach Here are my key take aways from Ed’s learnings on software architectural approaches:
Key Take Aways on Architectural Antipatterns Antipatterns are what not to do, or in the words of Jim Coplien -- "an anti-pattern is something that looks like a good idea, but which backfires badly when applied." Here are my key take aways from Ed’s learnings on antipatterns:
These are just my notes and take aways from Ed’s illuminating post. Ed’s actual post is rich with elaboration and examples, and it connects the dots. Check out Architecture, Mobiles, and Health: 10 Pitfalls.
Today I gave another talk on Getting Results the Agile Way to a fellow team in Microsoft. While putting together this talk, I needed a way to tie everything together. The message I finally settled on was this:
Be the author of your life, a story at a time, a day at a time …
Obviously that's a metaphor, but it really brings to life the idea that Getting Results is a story-driven approach for getting results in work and life. While it combines some of the best practices for focus, time management, energy management, and productivity, the most important thing is that it puts YOU front and center. After all, the person who is most impacted by your decisions is you. Who cares about any results if they aren't meaningful for you, or if they don't move you towards the person you want to be or the experiences you want to create.
This is a comprehensive roundup of our patterns & practices performance guidance for the Microsoft platform. I put it together based on customers looking for our performance guidance, but having a hard time finding it. While you might come across a guide here or a How To there, it can be difficult to see the full map, including the breadth and depth of our performance guidance. This is a simple map. organized by “guidance type” and topics
Performance “Blue Books” Blue Books have played a strategic role in both shaping the platform and driving exponential customer success on the platform. They’ve helped us find and share platform best practices, create mental models and conceptual frameworks, and create systems and approaches that scale success: The following are the patterns & practices Blue Books for performance:
For more information on patterns & practices Blue Books, see The Power of Blue Books for Platform Impact.
Performance Engineering (Design / Testing) This is our body of prescriptive guidance for performance design and testing:
Topics This is our body of prescriptive guidance for performance organized by performance topics:
Techniques for Performance Testing (A-Z)
Sometimes the big gets in the way of the small. While it’s great to package up value into a bigger set, sometimes this blocks flowing smaller value as you go. For example, maybe you have a big idea that blocks your little ideas. Or maybe you have a product that packages up a lot of value, but you can’t ship it until it’s all done. In either case, it blocks the flow of value.
The Big Blocks the Small Here’s a simple visual that shows all the work in progress that piles up while waiting until it’s all done and ready to go as a monolith:
In the above, imagine that all the little chunks of value are being treated collectively as one big chunk of value – and it’s not done until it’s all done.
The Small Flows the Value Here’s a visual that shows the small flowing value. Each little chunk of value is completed and made available:
From a metaphor standpoint, this might be like your waiter bringing out food as it’s ready instead of waiting until it’s all ready then bringing everything out at once.
Find a Way to Flow Value In the early days of patterns & practices, my manager put a lot of pressure on me to find a way to flow value. He didn’t like the fact that while the team worked on a Blue Book or guide, there was nothing available along the way. We found a way to make our smaller guidance nuggets available along the way (How Tos, Checklists, Guidelines … etc.) as part of a community knowledge base in CodePlex before our final release as a full guide on MSDN.
What I’ve found is that flowing value helps test your results and get real customer feedback along the way. Additionally, internally it helps show stakeholders that you’re producing results and making impact. This is often a key to continued funding and support.
I was reading through Corey’s post on Scrum-ban again, and I really liked his point that assigning all the work up front during an iteration plan creates an artificial critical path:
“Another common technique is the late binding of tasks to owners. Some teams will pre-assign all of the known tasks during iteration planning. That’s generally not a good idea because it artificially creates a critical path. Waiting until the “last responsible moment” to assign tasks to people maximizes knowledge and brings you closer to pull.”
It was something I had bumped into multiple times but hadn’t put into words. Early on, I was on two-week iterations. This meant my iteration planning meetings had to be long enough to figure out two weeks worth of work. Worse, even when people were good at estimating their work, it did create this artificial critical path.
Shifting to weekly iterations and estimating just enough work for the week, while knowing the next best things to do, dramatically reduced the overhead and complexity of managing the work. It helped the team respond to bottlenecks and avoid overloading their backpack on a daily basis. It also helped put an extra focus on reducing open work and bringing things to close before starting new work. Ultimately, this helped the team flow value and shift to more demand-driven or pull over supply-driven or push. Responding to demand in today’s world is a good thing, as we lean down, and provide value up.