A Bit on Power Toy Philosophy

We’re getting ready to release a ton of new TFS Power Toy news in the next few days and as I’ve been preparing for it, I’ve found myself reflecting on what Power Toys are about. I don’t pretend to be pontificating any official Microsoft policy here but I wanted to share a few thoughts.

Some Background (skip if you don’t care)

We (the TFS team) came up with the idea of doing “Power Toys” in the last 6 months of shipping TFS. Historically, the end of the product cycle in DevDiv is a grind. It’s months of testing, gathering customer feedback, triaging and fixing bugs. By the time we get past out final Beta, the product has all of the features that it’s going to and we’re just refining the quality, tuning the performance, etc. We may do a DCR or two if there is a huge amount of customer demand – the Work Item Tracking “friendly name” and improved Sharepoint setup experience are (I think) the only two we did at the end.

During this time, it’s easy to see all of the things we wish we could do. Holes in the product we wish we could fill, compelling new features we could deliver. With TFS being a V1 product, this desire is especially strong. But, it’s the wrong time. It’s time to ship what we’ve already built.

We found ourselves asking – If not now when? I posted a blog entry (way back then :)) asking what you want. Did you want a big release with lots of new value? A small release to fine tune what we have? Etc. Most of the feedback I got tended to be on the shorter more tactical side. On the other hand, there are some major advances we want to make too. And there’s the issue of coordinating our schedule with the rest of DevDiv. It makes for a very complicated problem to solve.

As we were mulling over the great stuff we thought we could do and trying to figure out when we could do it, we asked the unthinkable – what if we just build it and put it on the web and let people download it? We’re in a bit of a different situation than most products out there. We (TFS) are sold primarily as a subscription – not as a one time purchase with separate one time upgrade decisions. So, we thought, why not? We could build features and make them available immediately. You can’t use them if you don’t already have a TFS license and since you’re on subscription, we’re not taking away from our “upgrade” revenue.

That covers the revenue side of it but that’s only a small part. There are a lot of other issues, including: release process (testing, Beta testing, etc), marketing, support, localization, documentation, setup & servicing, etc. If we are going to release value off-cycle and frequently, we have to find a way to substantially reduce the “cost” of doing a release. This drives a lot of our policies around Power Toys.

What is a TFS Power Toy?

We use the term “Power Toy” loosely. It is a “brand” we use for a series of tools/add-ons that are released off-cycle from the “normal” DevDiv release process. The primary characteristics include:

Released as a web download. This is the easiest way for us to distribute something and allows for a very flexible release/update schedule.

Shipped about once a quarter. We’re actually doing a little better than this right now (about every 2 – 2.5 months) but we may ease up a bit. A release may contain new features or it may just have bug fixes to existing Power Toys. This more dynamic release process allows us to address bugs and pain points more quickly.

Pure “add-on”. Power Toys don’t modify any files shipped as part of an official release. The reason is that introduces risk and complicates our servicing story. More on this below. I’m not promising that no Power Toy will ever modify “official” bits – but it’s a strong guideline.

Delivers real value. Power Toys are not just random things we dreamed up one day. They are carefully chosen to respond to customer feedback. We go through a similar prioritization process for Power Toys as we go through for features for a major release.

Carefully chosen release overhead. There are many things that we do for a full product release that we don’t do for Power Toys.

Testing tends to primarily be accomplished by internal use, “bug bashes”, dev testing, etc. This is as opposed to the extensive investment we make in automated testing for full product releases.

We do very limited documentation and no localization. To supplement documentation, we write blog posts with samples, etc.

We do a basic setup with no servicing support. If you need a fix, you uninstall the old build and install a new one – very different from the “patching” support we have for our full product releases.

TFS Power Toys are not “Toys”. Despite the self-deprecating name, we take Power Toys very seriously. We use them internally in our production environment and we expect that customers will too. As a result we work hard to ensure that any feature is valuable, its user experience is good and quality is high.

Over the past several months, I’ve started to hear customers express concern about deploying TFS Power Toys into their production environments. I’d like to try to address these concerns and help people feel better about it. This blog post is one step towards that goal. Another step I’m considering is changing the name. I fear the name “Power Toys” is misleading. As I said, these are not toys. They are useful and solid tools. I’m VERY interested in hearing opinions on the idea of renaming them.

The Role of Servicing

Servicing is the process (Hot Fixes – aka QFEs and GDRs, Service Packs, etc) by which we update officially shipped bits. As I said above, Power Toys generally do not change shipped bits. However, there is some interplay here. As you’ve seen from some of my posts on SP1, we are now starting to add small features in our service packs. My plan is to add carefully chosen features to service packs that can later be leveraged by Power Toys to deliver value. This allows us to constrain the volume of work that has to fit in the tightly managed servicing schedule but still deliver substantial value as early and often as possible.

Conclusion

Time will tell what happens to the TFS Power Toys. For now it’s a bit of an experiement. If you, our customers, find them valuable and they help you get your job done, we’ll continue to do them. Over time, I expect many (but probably not all) Power Toy features to get integrated into a future “full release” of the product. I hope the feedback we get from releasing them early allows us to produce an even better feature by the time we incorporate it into an official release.

I appologize for the length but I had a lot to say (and a lot more that I could have, but didn’t). Please let me know what you think. Does this make sense? Are Power Toys useful to you? Is there something we should do differently?

Rob Caron on TF30331: Failure to Connect to Team Foundation Server and Fishing for Answers to Team System…

10 years ago

Gert C

Short release cycles for "Power Tools" sounds great. Satisfying feature requests from customers early and often is usually a good thing.

Gert C.

10 years ago

curedone

I personally had some problem explaining that philosophy to the (prospective) clients; they did not exactly want to use unsupported utilities that are provided out of scope of SCU they have purchased and out of scope of SCU service packs. And when those utility applications are supposed to be used for everyday tasks, the clients like it even less.

I believe they should be part of product and be supported; the name is not that relevant (though "toys" does not help much as well).