I’ve worked with different concepts taken from Microsoft Solution Framework since year 2000, so I can say I know MSF rather well. Most of the time it was version 3.x (3.0 and 3.1) of course, but I’m also familiar with fourth version delivered with Visual Studio 2005 Team System. However, when I accidentally went to MSF website I was surprised a bit. A lot of marketing babbling why MSF is so fantastic, a lot “we’ve integrated it with Visual Studio” stuff, instead of plain old white papers. That made me thinking once again about the way MSF went lately.
Differences between 3.x and 4.0 versions of MSF
Well, I shouldn’t be surprised. When I consider it, Microsoft just follows their MSF roadmap. A main milestone in version 4.0 was (I believe) to provide implementation for a whole idea described in version 3.1 and add some improvements also. What a nice goal to achieve. And they made it. I just wonder if the direction was right.
MSF in its origins was a toolbox. You could take from the toolbox tools you needed and use them in a way you wanted to implement your software development process as you liked. Now, MSF 4.0 replaced well-known toolbox with an IKEA pack – bunch of tools and parts and a detailed instruction how to put it all together, all within a single box. No place for your own invention. Microsoft delivers you a scenario they think you should work with. Of course you can work on your own implementation of MSF 4.0 customizing MSF process, so at the end you can have it done different way. The same is with furniture bought in IKEA – you don’t need to follow the instruction, but because whole process was designed to follow it, every other scenario requires more effort.
If I had to summarize a difference between MSF versions in one single sentence it would go like “MSF 4.0 is implementation of MSF 3.x, a kind of hardening it.”
What’s in it for me?
A reason why I don’t really appreciate new MSF, yet still permanently praise its older version is entry level. Implementing most of the concepts packed into MSF was rather easy – it could be done step by step without rapid rearrangement of current development process. Daily builds? OK, let’s look how we can adjust our build process. Risk management? Sure, maybe one of our tools can be extended with that functionality or maybe it’ll be enough to have a dedicated Excel sheet. Roles? We have to think for a moment if a team suits well to MSF role model, probably we should change some task assignments. Development cycles? OK, that’s where a lot of work should be done, but it’ll pay of.
With MSF 4.0 the implementation process is whole different. You need to start with implementing Visual Studio Team System. No, you need to start with buying VSTS, which can hardly be called “cheap” (I’m very tactful here). OK, let’s leave VSTS overcharging, a lot has been written on that subject. Suppose you’ve already implemented Team System and chosen scenario (Agile or CMMI) you want to follow. Now, you have to do most of work with adjusting your development process at once. It’s all tightly integrated so it’s hard to choose a single piece, than another and so on. Hey, it’s specific implementation now, not the toolbox any more. So better spend time on intensive training, than supervising and correcting whole process. Forget step by step approach.
That’s the easier case. You can find that neither of two methodologies (Agile or CMMI) proposed by Microsoft suits you well. Then, you need to choose one and customize it into something you want to achieve. You can also think about developing of your own process within VSTS if you like (and have a lot of money to spend). That’s heckuva lot of work, but no one forbids you to go that way.
I’m not sure if Microsoft did it intentionally (looking on VSTS price model I think they actually did), but MSF 4.0 is for big organizations. If you have a dozen or two of developers don’t even think about that. You most likely don’t need all the stuff new version brings and almost for sure you don’t want to spent as much money for implementing MSF 4.0. You aren’t the target customer for guys from Redmond. You should rather look on MSF 3.1 which is perfect for small companies. On the other hand if your company has hundreds of developers and mature development process MSF 4.0 is probably a wise choice.
Reasons of change
I haven’t changed my mind about MSF as a whole; I just don’t like the place where Microsoft took it. Why they did it? I can’t be sure, but I believe they had wide range of reasons. My guesses are:
• Leveraging VSTS premiere. MSF 4.0 and VSTS are tightly coupled. New MSF can hardly live without Team System.
• Addressing MSF to large companies. MSF wasn’t considered as methodology appropriate for big software companies. Microsoft struggles to change this opinion.
• Limits in old MSF scalability. That’s just a speculation, but probably Microsoft faced some scalability issues with MSF within the company. I see some weaknesses of version 3.x in the area of arranging information – with version 4.0 a newbie in the team has a lot easier to find out what she has to do.
• Monetizing MSF success. MSF became quite popular, but it wasn’t something Microsoft made money from. Pulling MSF to higher shelf and adding tools (VSTS) is a method to gather some cash from this channel.
Nevertheless, changes affected basis MSF was built on. I don’t treat version 4.0 as upgrade, but rather as another branch that has risen from the same tree. And in many cases I’ll stay with the old version.