Around mid 2004, Randy Miller approached me with "I want to review MSF Agile with you with the idea of incorporating your work." I didn't know Randy or what to make of MSF Agile, but it sounded interesting.
Randy wanted a way to expose our security and performance guidance in MSF. Specifically he wanted to expose "Improving Web Application Security" and "Improving .NET Application Performance" through MSF. I was an immediate fan of the idea, because customers have always asked me to find more ways to integrate in the tools. I was also a fan because my two favorite mantras to use in the hallways are "bake security in the life cycle" and "bake performance in the life cycle". I saw this as a vehicle to bake security and performance in the life cycle and the tools.
We had several discussions over a period of time, which was a great forcing function. Ultimately, we had to figure out a pluggable channel for the guidance, the tools support and how to evolve over time. My key questions were:
- how to create a pluggable channel for the p&p guidance?
- what does a healthy meta-model for the life cycle look like?
- how to integrate key engineering techniques such as threat modeling or performance modeling?
- how to get a great experience outside the tool and a "better together" experience when you have the tools?
These questions lead to a ton of insights around meta-models for software development life cycles, context-precision, organizing engineering practices and severl other concepts worth exploring in other posts.
My key philosophies were:
- life cycle options over one size fits all
- pluggable techniques that fit any life cycle over MSF only
- proven over good ideas
- modular over monolithic
Randy agreed with the questions and the philosophies. We came up with some working models for pluggable guidance and integration. His job was to make the tools side happen. My job was to make the guidance side happen. I now had the challenge and opportunity of making guidance online and in the tools. This is how I ended up doing guidance modules for for .NET Framework 2.0. This also drove exposing p&p Security Engineering which is baked into MSF Agile by default.
Randy summarized our complimentary relationship best ...
“The Patterns and Practices group produces an important, complimentary component to what we are building into MSF. In Visual Studio, our MSF processes can only go so deep on a topic. Our activities can provide the overview of the steps that a role should do but cannot provide all of the educational background necessary to accomplish the task.
As many of the practices that we espouse in MSF (such as threat modeling) require this detailed understanding, we are building links into MSF to Patterns and Practice online material. Thus the activities in MSF and the Patterns and Practices enjoy a very complimentary relationship. The Patterns and Practices group continues to be very helpful and our relationship is one of very open communication.“
Mike Kropp, GM of our patterns & practices team, liked the results ...
“– it was great to see the progress you’ve made over the past couple of months. here’s my takeaway on what you’ve accomplished:
- you’ve agreed on the information model for process and engineering practices – I know this was tough but it’s critical to achieving alignment
- the plug-in architecture allows us to evolving the engineering practices and serve them up nicely for the customer – in context
- the model you’ve come up with for v1 allows us to adapt & evolve over time (schemas, types, etc..)
... this is a great example of how we can work together to help your customers and partners.”
I remember asking Randy at one point, why did you bet on our security and performance work? He told me it was because he knew we vetted and proved our work with customers and industry experts. He also knew we vetted internally across our field, support and the product teams. I told him if anybody wondered who we worked with, have them scroll down to the contributors and reviewers list for the security work as an example.