Team Explorer Everywhere 2010

We've finally announced the release of Team Explorer Everywhere 2010¹ and now that we're finally done, I can say without any hesitance that this is the proudest I've ever been to have shipped a product. Yes, we've added a lot of new features, but I'm much more proud of the huge increase in quality... that almost didn't happen.

Right after the Teamprise 3.0 release, we stepped back and took a hard look at the codebase for our UI products. We'd done the typical startup engineering effort way back in the 1.0 days: basically, quick and dirty, and we cut some corners. Some of the code between Teamprise Explorer and our plug-in for Eclipse was duplicated, in order to adapt between Eclipse IResources and the model objects we used in Teamprise Explorer. This was a pretty thin layer of duplication, but whenever there was a bug there, we had to remember to fix it in both places. More annoying, however, was that some of the more advanced controls - like the Pending Changes View - were written back before we all had a firm grasp on the SWT toolkit and as we added more functionality, those controls became increasingly problematic. The worst, however, was our very brittle contact points with Eclipse. The Eclipse IDE lets you perform very advanced, and very powerful, refactoring operations that we couldn't always convert to the representative TFS pending changes.

We realized after 3.0 that we simply couldn't keep moving forward with our UI code base in the shape that it was. We decided to undertake a rewriting of our entire connection experience, all the places we interacted with Eclipse, all of the shared code between Teamprise Explorer and the Plug-in for Eclipse and many of the advanced controls like the Pending Changes View. This was a pretty bold undertaking - the history of software engineering is littered with examples of why you shouldn't do the "big rewrite". But we were convinced that we could make some very important changes in our framework² and still leverage a lot of our old code. That is, do a big rewrite without doing a "big rewrite", and launch this new version around the same time Microsoft shipped their next version of TFS.

Of course, what we didn't take into account was that Microsoft would acquire us halfway through our development cycle and we'd suddenly have to peel off from development to do a lot of due diligence, then move halfway across the country and integrate into a whole new company in the middle of our big rewrite. So in the middle of November, when we all flew to North Carolina for the first time to meet the rest of the team and get them up to speed on our software, we had a very awkward meeting.

"Well," I said, standing in front of a whiteboard drawing out our architecture. "This is more or less how it's supposed to work. The good news is that it's a pretty good architecture... I think. The bad news is that it's not done... and it's not at all proven."

So we talked about the big rewrite a little bit longer and then we had a tough decision to make. Do we keep going down the road of the rewrite, with a hard ship date staring us in the face? Or do we throw it away and go back to the old Teamprise 3.0 codebase and just fix what we can and add some new features?

After a lot of debate, we decided to keep going with the big rewrite, with (scarily aggressive) milestones to make sure that we were making the right decision and could still back out if we needed to.

Fortunately, we didn't need to. Thanks to some herculean efforts on the part of the entire team, we completely rearchitected our clients for Team Explorer Everywhere 2010... and thanks to some excellent testing, we've been held to a much higher standard, too. This is - without question - the highest quality release of our plug-in for Eclipse that we've ever done, and we couldn't be prouder.