This post is the 6th in a series that started with the 10 practices that every developer needs to start right now

The first time that someone taught me about Software Design Patterns it went something like this:

• Them: “… and so that is the pattern.”
• Me: “That’s it”
• Them: “Well, yeah.”
• Me: “But that’s how I’ve always done that.”
• Them: “Well, then you’ve always been following that pattern”

I find that is how a lot of people react when they first learn about patterns. “So a pattern is just giving a name to good software development” Well, yes and no. On the one hand – yes, a software pattern is recognizing common software challenges and the approaches that have worked in the past to over come those challenges – and naming it. On the other hand, don’t underestimate the power of giving something a name.

Vocabulary

There is power in a common vocabulary. Think about it, every profession has one. From the dentist that cleans your teeth to the short order cook at Denny’s; from the mechanic that works on your car to the contractor that built your house. Every profession has it’s own vocabulary that gives people a fast and efficient way to communicate.

So that instead of taking time to walk through all of the details of your architecture and application design, you can have a conversation that goes something like this “We’re writing a facade layer here, and utilizing a DI container to act as our Abstract Factory, accessing our persistence layer with a repository pattern utilizing Interception for logging and MVVM to composite all of our UI.”

OK, so I know that there were a lot of buzz words thrown in there, but I hope you’re getting the point – a lot can be communicated in a couple of sentences.

Patterns

Let’s face it – there is more to learn than any of us has time for. Patterns are like that. There’s a pattern for everything – like a bad Apple commercial, there’s a pattern for that. The important part is not learning every pattern under the sun – but learning the common patterns for the common challenges is where you’ll get the most bang for your buck.

Component Patterns

Strategy | Factory | Abstract Factory – all related.

Factory. The goal of a factory pattern is to conceal the creation of an object from the consumers of the object. This is especially important for complex objects that take a lot of dependencies or configurations when you create them. Instead of repeating the set up code through out your application you move it to one place (the factory) and then call that from your code.

take this (slightly contrived) code example…

            SqlCommand cmd = new SqlCommand();

            SqlParameter parm1 = new SqlParameter();
            parm1.Direction = ParameterDirection.Input;
            parm1.ParameterName = "Id";
            parm1.Value = 5;
            cmd.Parameters.Add(parm1);

            SqlParameter parm2 = new SqlParameter();
            parm2.Direction = ParameterDirection.Input;
            parm2.ParameterName = "State";
            parm2.Value = "TX";
            cmd.Parameters.Add(parm2);

            // etc...
       

It would be much nicer to implement a reusable method as so…

      SqlCommand cmd = new SqlCommand();
            cmd.Parameters.Add(getInParm("Id", 5));
            cmd.Parameters.Add(getInParm("State", "TX"));

            // etc...
        }

        SqlParameter getInParm(string name, object value)
        {
            SqlParameter parm = new SqlParameter();
            parm.Direction = ParameterDirection.Input;
            parm.ParameterName = name;
            parm.Value = value;
            return parm;
        }

       

This probably seems like an obvious and simple example (because it is), but the point is that not all patterns are ground breaking or earth shattering, just simple approaches to make your code more usable, maintainable and testable.

Abstract Factory. If you set up your factory to return an Interface instead of a concrete class then it is an abstract factory. This is especially useful when you want to return different implementations in different scenarios. For example, you might have an IDataLayer and in some cases you want to return a fake version for testing, or perhaps you need a local storage version for offline scenarios etc.. moving the creation of your data layer, it’s configuration and set up to a factory would make a lot of sense. By the way, this is also a text book definition of Object Oriented Polymorphism – the same interface with different behaviors with various implementations. And that brings us to the Strategy Pattern.

Take our example above, if we were to move that bit of code in to a shared data access helper class, we might want to consider a more generic approach.

      IDbDataParameter getInParm(string name, object value)
       

Strategy Pattern. The original goal of the strategy pattern was the grouping various algorithms in to common interfaces. So, for example, working with DES, Triple DES or Blowfish encryption shouldn’t be any different than driving a V8 is different from driving a 4 cylinder car – what’s under the hood (the implementation) doesn’t matter as long as you know hot to use the steering wheel and pedals (Interface). No code examples here. Go take a look at encryption in .NET, or the common approaches that ADO uses for data access. Also, hang on, we’ll go in deeper to code examples in just a bit when we talk about composition over inheritance (which is closely related to Strategy Pattern)

Up next: UI Patterns for Testability, Maintainability and Extensibility!

(Followed by Composition over Inheritance)

Images Credit: http://www.flickr.com/photos/webtreatsetc/4229661317/sizes/o/

Last week I had the privilege of attending Microsoft’s Global MVP Summit in Bellevue Washington. While I can’t talk about most of what was covered (NDA) I wanted to mention two projects that I learned about while there and mention some of my thoughts from the event.

First, check out these two Silverlight projects on Codeplex.

• The Silverlight Hyper Video Player
  On Thursday, Jessie Liberty presented on this project that he’s been leading. I actually got to see a preview of this project last year with one of the developers, but they weren’t sure back then if they were going to be able to release this project as OSS or not. Glad to see that it was! Go check out the project, it’s a great Silverlight project demonstrating TDD in Silverlight as well as using the new features of MEF for composition that are built in Silverlight 4.

• The Silverlight User Group Website Starter Kit
  A friend of mine, David Silverlight, brought this project to my attention. I love this idea! He and a talented group of developers and designers are working on this project to give user groups a great starting point and some excellent features to leverage. I’ve actually been added to the team and hope that I’ll be able to provide add to the final result!

Final thoughts

There are multiple reasons that Microsoft organizes and hosts the MVP Summit. Part of it is developer satisfaction and to show appreciation for the work that MVP’s do around the world. MVP’s attend to gain insights in to Microsoft’s direction, network with product teams and gain a deeper understanding of the products that they work with day in and day out.

The last reason that I want to mention is to give the MVP’s a chance to provide input back in to the products that Microsoft is building, to be able to tell the product teams what they are doing right, what they are doing wrong, and help prioritize the features that the product teams should be working on.

This was my fourth Summit to attend, and the first time that I really saw this last point taken to heart across the board from multiple teams. I was really excited by the feedback that the product teams were actively soliciting from the MVP’s. I consistently saw and participated in agile techniques like dot voting and buy a feature around broad functionality, specific features and general direction for the product teams. It was very refreshing and opened up a ton of conversations that probably wouldn’t have happened otherwise. Thanks Microsoft!

Microsoft Campus Photo Credit: Denis Gobo

This post is a part of a series that I started with “10 Practices that Every Developer Needs to Start Right Now“.

Update: This post was picked up by DZone, go vote it up!

Ok, before you dig in to the post, let’s get two things out of the way first.  1.Go read the authority on SOLID principles from the man himself, Uncle Bob Martin.  2nd.Go get the very cool Inspirational SOLID images from the guys over at Los Techies. They released them under a Creative Commons License which I think is pretty cool! Alright, got that out of the way? Good. Let’s get started.

Few things have come a long OO history that resonate so well with so many developers than the SOLID principle. One of the reasons they resonate with so many developers is because they communicate several practices that many developers have been doing all along. The beauty and power of the SOLID principals in in there ability to communicate, what I call code architecture, in such a memorable and practical way.

Like any good thing, however, taken to an extreme can become a hindrance on any project. So, I’m going to tackle these principals like I tackle everything in this series… give you my take on it. So here you go: SOLID according to Caleb.

[SOLID Motivational Posters, by Derick Bailey, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License. Get them here.]

S – Single Responsibility Principal #

“There should never be more than one reason for a class to change.” — Robert Martin, SRP paper linked from The Principles of OOD

Abuse: I’ve seen this taken to an extreme. I’ve seen good clean readable code turned in to multiple classes (even multiple projects) to break up “responsibility”. The end result was much harder to maintain and even harder to read.

Applied: “One reason to change” does not mean that every class has one and only one thing (that would be called a method), it does mean that you should focus on the area (or areas) of responsibility that a class should have and then stick with those boundaries. Code bloat (overly large classes with overly large methods) is a real code smell that you need to watch out for. The more things that a class is responsible for, the more likely you’ll have to change it and the harder it will be to test.

Your code should be broken in to manageable pieces, reduce any unnecessary couplings… Practice writing Libraries not Frameworks.

O – Open Closed Principle #

“Software entities should be open for extension, but closed for modification.” — Robert Martin paraphrasing Bertrand Meyer, OCP paper linked from The Principles of OOD

Abuses – I’ve worked on code bases that were so extensible, so configurable, so full of AOP indirection and configuration that following the flow of what they were actually doing was almost impossible.

Applied – Code is going to change, that’s a part of life. The Open Closed Principal is more about reducing how often you have to change your code and in how many places. In other words: Code to Interfaces and maintain your abstraction boundaries.

I recently worked with a Linq to SQL project where the Data Context object was being passed around through out all of the layers in the application. That meant that most of the application was impossible to unit test and if I were to change a column or table in the database I would have to go through the entire code base and find all of the places that broke. We fixed that by creating a specific data interface that all interactions had to go through, only passing domain objects (DTO Models). We kept the DB Context in the Data Layer implementation where it was super useful, but no longer forced us to recompile the entire source for simple data changes. I like how approach that Jeffery Palermo described and an Onion Architecture.

I also worked on another project where 8 layers of abstract classes were used to distinguish between three different types of physical devices… any change in the application behavior had to be propagated across all of the implementations. We fixed that by concealing the device differences behind a single command interface that was then injected in to the application “behaviors” via an abstract factory.

What did you just say?

So in other words… imagine having three different devices (blue, red, green) that all needed to be turned on (behavior), but the command to turn on each was different and defined by the manufacture… the code *might* look like this:

Now imagine that there were multiple points within your application where you were working with the devices… now, every time you need to support a new device you end up with this if/else statement being redone just about everywhere…

By externalizing the device differences behind a factory and encapsulating them in an Interface you now only have one place to change to add a new device. You could reduce that further using an extension manager like Microsoft MEF, but we won’t go in to that right now.

L – Liskov Substitution Principle #

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.” — Robert Martin, LSP paper linked from The Principles of OOD

Abuses: I like to think of this principle as “Use Interfaces”.  I haven’t really seen abuses of this practice, but I have seen some bad implementations. The rough ones, are where developers rely on a base abstract class instead of an Interface also. The doesn’t sound like a problem until you start putting parameters in the constructor of the base class. Now any derived classed have to enforce those same dependencies even if you are creating an entirely different implementation.

Applied: Use Interfaces. If you find that a base class would meet some of your needs more closely, that’s fine, just make sure that you back that base class up with an Interface, and then code to the Interface.. you’ll thank me later.

Side Note: Their are different schools of thought around backing domain models with Interfaces. I do, the main reason is that even if I end up using an ORM (like Entity Framework, or LinqToSQL) that “forces*” me to a specific domain model implementation, I can save myself a lot of headache later and make my models more mobile if I connect those domain models to an Interface.

* – no toolkit should force your architecture or design, any implementation can be abstracted around, Domain Model Interfaces help move your DTO’s through layers of your application without carrying heavy dependencies with you.

I – Interface Segregation Principle #

“Clients should not be forced to depend upon interfaces that they do not use.” — Robert Martin, ISP paper linked from The Principles of OOD

Let’s say you have a service class for working with Invoices, your IManageInvoices interface exposes three methods, Add(IInvoice), Delete(IInvoice) and Update(IInvoice). Because of deployment and security concerns you are going to create two different classes to implement this.

One, InvoiceCreator will implement the Add method and run in untrusted environments. The other class, InvoiceUpdater, will implement the other two methods and will only run in secure, verified and authenticated context. So what should each class do with the other methods?

Violated: One “option” would be to implement them, but then throw a “Not-Implemented Exception” or set up Void methods that don’t actually do anything, both of those options are ugly and bad choices.

Applied: The better option is to split your Interface, create a ICreateInvoices Interface with the Add method, and a IUpdateInvoices interface with the other methods. That way, you are actually implementing the methods of your interface, and are not hiding are making implementation decisions that break your abstraction and require special knowledge of the class.

D – Dependency Inversion Principle #

“(A) High level modules should not depend upon low level modules. Both should depend upon abstractions. (B) Abstractions should not depend upon details. Details should depend upon abstractions.” — Robert Martin, DIP paper linked from The Principles of OOD

All code has dependencies, the question is how to you resolve those dependencies.

Example: my class will access a service, I could write it like this:

or like this:

Can you spot the difference? It’s subtle, yet very very powerful. In the first instance, you are using an Interface to define your Shipping Service (and that’s a good thing!), but then you are forcing your class to be dependent on the UPS shipping service… I don’t have anything again UPS, but I do know that company contracts are constantly changing, and just because we were using UPS when we designed and had the customer (business owner) sign off on the application, doesn’t mean that that’s who we are going to use when we go to production!

You might be tempted just to replace the “new UPS” instantiation with an Abstract Shipping Factory ( shipService = factory.getShippingService() )… that wouldn’t necessarily be a bad idea, except now you’ve shifted your code from a UPS dependency to a factory dependency.

Notice in the second option, we hand our class the implementation that we want to use through the constructor. That’s called constructor injection, we could have also used a property or method to set the shipping service. I like constructor injectors for anything that my class requires to operate. This allows us to define our IShipping service implementation completely independent of the class that’s consuming it.

This also makes are code much easier to test by allowing us to creating a mock (fake) version of our IShipping service for testing the main class. We might even use something like RhinoMocks to help our automated unit tests even more, but we’ll save that discussion for another time.

No Framework Required

You may have noticed that this dependency injection is not dependent on any special tooling or frameworks (so we’re not introducing new dependencies just to get rid of another!)

Dependency Injection or DI, is really a style of coding that makes your code more composable, testable and maintainable. DI Frameworks (or Containers) are specifically designed to be used in two stages.

Register, then Resolve

First, you register your Interface to Class mappings, then you can reference the container anytime and resolve an Interface to a concrete class. Containers can also provide other nice benefits like controlling the life cycle of an object (singelton, vs per thread, vs per request for example). Some DI frameworks also provide the ability register special handlers (or Interceptors) that get invoked whenever a method or a property is called. This in a concept known as AOP or Aspect Oriented Programming that is useful for cross-cutting concerns like automatic logging and security checks.

For more information on Dependency Injection and Inversion of control I suggest checking out my DI in Silverlight slide deck, as well as the Ninject, Castle, Microsoft Unity and Structure Map projects.

Enjoy!

I’m starting off this series talking about Object Oriented Programming. It’s amazing how many people write C# or VB (.NET) with long, procedural methods with really no understanding of the true fundamentals of OO design.

I know, I know – it’s not you, and know what? I’m not talking about you.. but check out the code from the person next to you. See what I mean?

Just because you’re writing in an OO language, doesn’t mean that you’re writing OO code, or taking advantage of the Object Oriented benefits. An Object Oriented language is more than classes with methods, properties and events (even VB 6 had that!).

Learn the Fundamentals.

Get to know Interfaces, abstract classes, structs. I’m not picking on the thousands and thousands of extremely talented .NET developers that came from VB6 (I’m one of them), but I am acknowledging the fact the there are OO tools and strategies at your disposal now that never were before.  Dig in to the delegates and the various eventing models, chained constructors, virtual and overridden methods. Go beyond if statements, while loops and language syntax similarities and embrace your new polymorphic self.

Perhaps, you’ve been a very successful developer for a very long time, I’m not saying that you have to change how you write all of your code. I am however, suggesting that you should realize that you have more tools in your toolbox than you might be aware of, and that if you learn how to use those tools, you will be more successful using the right tool for the right job.

Go beyond the fundamentals. A friend of mine teaches Object Oriented Analysis and Design for SMU, he once told me that if you have to use an if statement in your code then you’re not doing OO – it’s now procedural. I think he meant his statement in jest, (Although, he actually doesn’t allow his students to use if statements past the third section in his course) but the point was well taken. Beyond language semantics lie’s a whole world of patterns, approaches, and ways of doing OO that can make your life much, much simpler.

Pragmatic – Make new friends, but keep the old ones..

I’m not that much of an OO purist. I actually do feel that sometimes a well laid our “procedural” method can be easier to read, and communicate the intent of the code, but it’s a balancing act. Every time you write an if/switch statement you fork the flow of your code and increase it’s complexity, reducing your ability to maintain and test it. An OO purest might create a polymorphic object at this point and hop over to it instead of writing that if statement. I’m not saying that one way is better than the other. Like I said, writing readable/maintainable/testable code is a balancing act.

Beware of being “too” OO. It’s easy to get too pure on your OO. I’ve worked on systems where I had to fight through 7 to 8 levels of inheritance debugging and fighting all the way to figure out what in the world the system was doing. I’ve seen developers take 30 lines of procedural code and convert them in to 60 or 70 unique classes spread out over 6 projects. You can have too much of a good thing!

Is it OK to be “procedural” sometimes… can you be too OO?

The truth is, you want to use the right tool for the right job. The code on top is probably pretty readable and is fine… *right now* it won’t be too long and you’re going to want to start moving it closer to something like on the bottom. Why? With every scenario, and rule that gets applied to shipping orders, this code becomes less readable and harder to test. It won’t be long until you’re going to want to start validating (unit testing) your various order processes independent of each other. You’re going to want to break apart the coordination of an order, determination (the factory) of an order, from how it is actually handled… as you do that, your code will start to become more SOLID… but we’ll save that for the next post.

Interview Question Alert

Some of the related questions that I often ask:

Q:What’s the difference between an Interface and an Abstract class? When would you use one over the other? What implications does that have?

A: Interfaces define the contract with zero implementation, Abstract classes can have some implementation, but for the most part don’t. You can inherit from one base class, but implement as many Interfaces as you’d like to. Abstract classes can be versioned (if you’re going to strongly name them) but Interfaces cannot be versioned. Bonus Answer: Whenever you create an abstract class, you should always have an Interface to go with it, then code your dependencies to the Interface, not the abstract class.

Q: “Polymorphic” is a big OO word that developers like to throw around. Give a practical example of when you’ve used polymorphic behaviors in your code.

A: Anytime you use an abstract factory you’re implementing polymorphic principals. So the “processor.Process()” method above would be an example of Polymorphism, so would most Interface based development.

Further Reading

I hope this post has inspired you at some level to keep honing your development skills. I know that it was heavier on the “why” and low on the “how” specifics… I think that’s part of the point. You’ve got to go tackle some of this yourself. So go on, get out there.

Wikipedia – http://en.wikipedia.org/wiki/Object_oriented

Book: Object Thinking – MS Press

What are the resources that have helped you the most in your software development?

Photo Credit: http://www.flickr.com/photos/wwworks/sets/72157594328095699/

If you are going to read through my “10 practices that every developer should start right now” series, then you probably want to know where these 10 practices came from, why I chose these 10 – really, what so important about secure coding anyway?   – I think that it’s important to know that these aren’t just 10 random items to fill a couple of blog posts. These are all practices that have been thoroughly thought out. This list is something that I started to formulate over a year ago based on my experience as a consultant, working as a technical editor, and discussions with countless MVPs, other consultants and in my interviews with potential consultants…

Experience. First, these 10 practices have come from over 15 years of professional development work, working with countless customers when I was at Microsoft, as well as the numerous development shops and enterprise customers that I’ve been a consultant for over the last many years. These are, what I consider, to be the biggest bang for your buck, the low hanging fruit that you can quickly implement and the practices that will yield the greatest value in the shortest time.

Writing a Book. I once had the privilege of working as a Technical Editor on a C# 3.0 book. That experience was both rewarding and frustrating. It was rewarding to go through the process, engage with the executive editors, author and see the whose process of writing a technical book move forward. It was also frustrating to know that – while everything in the book was technically accurate – it often was not the content that I would have wanted to cover. These are the things that I want to talk about.

Hiring. Over the years, but especially during my time as a Principal consultant for Improving Enterprises and now as the Senior Software Architect for Six Flags, I’ve spent countless hours interviewing various – really smart people – that often fell short. (I’m a nice guy – but apparently a pretty heavy handed interviewer). I’ve discovered that the things that matter in software development – are often not taught, even in the best schools. These are the topics that I wish every CIS/ MIS department would start covering to some extent. I sometimes wished that I had a “quick read” book that I could hand to people on their way out and say “here, read this. This is what you should know before you try to work here.”

Scope – Obviously any one of these topics could be a whole book in and of itself. So none of these posts are going to be intended as a “complete” reference or anything like that. More like “Caleb’s thoughts on the matter.”… and hopefully some useful insights, and enough information to let you, Dear Reader, move forward and know where to go from here.

So that’s my introduction. I hope that you’ll join me as we dig in to all 10 practices.

Enjoy the ride!

photo credit: flickr

Update: Since technically a DI Container could be considered part of SOLID, I’ve swapped it out for Secure Coding… more on this soon!

If I ever right a book on becoming a .NET Ninja, these are the things that I want to cover.

Introduction

OO

SOLID

Use a Container (DI)

Secure Coding 101

Patterns

Automated Tests

Source Control

Continuous Integration

Agile | Lean | Scrum | XP

Team Dynamics

Never Stop Learning

Eventually, I’d like to write a book and dedicate at least a chapter to each of these (although any one of these topics could be a book in and of itself) In the mean time, I think that I’ll start with a blog post on each one, and maybe make it a goal to eventually do a User Group talk covering each topic? I’m looking forward to flushing these out as posts. I hope that you will enjoy them too!

What sort of things would you add to the list?

Last month (November 4th, 2009), I had the privilege of speaking at Microsoft’s “The New Efficiency” Launch for Windows 7 and Windows Server 2008 R2 in Dallas. While no one was there to record *my sessions* specifically, Microsoft has posted similar session from other parts of the country. I wish I could link (or embed) them directly since it takes some clicking to get to them. Instead, here’s a quick walkthrough. Enjoy!

1. Go to Microsoft’s “The New Efficiency” website http://thenewefficiency.com *

* Site requires Microsoft Silverlight

2. Click on the “Watch The US Event” link

3. Check out all of the “For Developers” videos…

4. Sit back, and enjoy.

Last Thursday I posted my thoughts about Microsoft’s OSS announcements (go digg it: 3 Reasons Microsoft Needs an Open Source Officer), namely the formation of the CodePlex Foundation (awesome) and the departure of Sam Ramji (bummer). My take is that this is a great opportunity for Microsoft to take open source projects at Microsoft up a notch and raise the stakes with a big bold move by bringing in someone like my friend whurley (William Hurley – currently the chief architect of open source strategy at BMC).

This morning I turned on my computer to see that Todd Weiss and the folks at Linux.com had featured this idea on their home page. Go check it out the full article!

While I was out at the MVP Summit this summer I had a chance to catch up with Brian Prince from Microsoft and we talked about using Dependency Injection for better code level architecture.  Check out the full video on Microsoft’s ARCCast.

When you’re done. Check out my Dependency Injection on Silverlight presentation.

Today there were two big announcements from Microsoft regarding their involvement with the Open Source communities. First, was the formation of the CodePlex foundation, an open source foundation for the

Enabling the exchange of code and understanding among software companies and open source communities

Awesome. Great. Fantastic. This is the natural progression of a lot of the open source work that’s been happening at CodePlex, in the ASP.NET MVC stack and a lot of the other OSS projects that Microsoft has been initiating and contributing to lately.

The other announcement was more disappointing, Bill Hilf, the general manager of Windows, announced that Sam Ramji would be leaving his post at Microsoft to be the interim president of the CodePlex Foundation (cool – but why interim?) and then he would be pursuing some other opportunity.

Sam’s primary focus is to drive Microsoft’s Linux and Open Source Strategy, working together with Microsoft technology development teams and open source communities to build interoperable solutions

Horrible. Tragic. What a loss. At least, that’s what I thought at first. The truth is that Sam is leaving a much different Microsoft than the one he joined three years ago. A better, more open Microsoft. I agree with Bill’s assessment,

Microsoft’s open source strategy is no longer just locked in a single ‘lab’ on campus – now OSS is an important part of many product groups and strategies across the company

Sam’s role seems to be that of an OSS advocate, working to build OSS awareness and acceptance from group to group within Microsoft. Well done. Mission *mostly* accomplished.

So where does that leave us? I believe that at certain times in history a company like Microsoft will be faced with opportunities. Opportunities to move boldly forward or slink back in to the status quo, and (to quote that great philosopher and social commentator Dr. Horrible) the status, is not quo. I believe that now is the time for Microsoft to up the ante.

Rather than replace Sam, with yet another “Senior Director” – how many of those are at Microsoft? – I believe it’s Microsoft’s time to embrace an OSS strategy that moves beyond the director level. They need to show the world a bold move, similar to what BMC did over 2 years ago. Microsoft needs an Open Source advocate with teeth.

Three reasons Microsoft needs an Open Source Officer

1. The Timing is Right – The Momentum is there.
   Change is in the air. Sam is moving on. The Codeplex foundation has launched, there’s a new Chief Architect in town, and Microsoft has embraced many aspects of OSS is so many areas of their business because they have realized that – when it makes sense and in the right environment, OSS is good for business and good for your customers.
2. It’s a different world out there.
   Not only has the world inside of Microsoft changed, so has the competition. Microsoft is increasingly competing in an open web world, with open standards against open platforms. More and more, these competitors also become their partners and customers.
3. Go big or go home.
   I believe that it is the spirit of Microsoft to take on new challenges, to put there money where there mouth is, and to embrace a big future with a strong vision.

Who should they hire? Well, I’m sure there are a lot of qualified people in this space, and I’m not going to mention anyone specific by name here… but if you follow my twitter feed then you might have seen something that I posted earlier today.

… and hey Microsoft, if you’re listening, I wasn’t the only one that thought that…

… I’m just sayin.