IIS Diagnostics Toolkit a la carte nears release, Third Time the Charm?

Ok... getting the IIS Diagnostics Toolkit a la carte MSIs released is really becoming a full blown soap opera that never wants to end. I last mused about it in this blog entry, and all I can say now is that despite having no development work done on it since February, it is still standing on deck.

The candidate build ended up having some problems with WFetch and missing help files, and getting that fixed with NO dedicated resources can take a while... :-) Things finally wrapped up last week, and we eventually got another candidate build with the fixes in it... and now it is bottlenecked on Chris doing some final verifications (again)... and of course, Chris is busy with many other things right now, so I have no ETA.

Sigh... I am looking at the signed MSIs right now, waiting for validation before it can get to downloads.microsoft.com and to be announced. There has to be a better way to do this...

As the consequence of an identity crisis, one of the ironic problems that the IIS team faces is that despite being a web server product, we have no web presence. We are not in charge of our destiny and hosting our own website on IIS7 anywhere.

Thus, in order to do simple things like provide files for download, we have to do it from downloads.microsoft.com... which means that we have to jump through many hoops and that just slows down progress.

Now, if the IIS team has its own web presence to host our own content, including file downloads... we may have a better chance to improve on the experience. For certain, I would not need to do administrivia like converting my working build system into an alternate system (like Windows OOB) just so that we can PAY someone else to push the big red button to satisfy some checkbox before getting onto downloads.microsoft.com. Hmm, why don't we just pay me instead; that probably would have solved the problem quickly, and everyone is happy. Nah. That would be thinking way too outside the box for these folks. ;-)

//David

Comments

• Anonymous
  April 25, 2006
  David, your frankness is refreshing! It seems as though Microsoft is stifling itself in bureaucracy (wrapped up in the words "policy" or "process") when you hear stories like this.
• Anonymous
  April 26, 2006
  DuncanS - yeah, such things exist in most organizations of sufficient size, Microsoft being no exception.
  
  However, I have to say that this "problem" tends to appear in the non-product-teams (i.e. those that provide services for others). If it was prevalent in the nimble product teams (which tends to suffer from a lack OF process, not stifled by process), Microsoft would not be able to release products.
  
  For example, Windows OOB is an organization dedicated towards "out of band" releases of Windows-related files, and it is definitely process driven. Similarly, Windows SE, organization dedicated towards "sustained engineering" releases (i.e. all the Service Packs, Hotfixes, etc come from them), is completely process driven.
  
  In some senses, these teams have to exist to free up those in the product team from this drudgery. You just hope to not have to deal with them constantly. :-)
  
  Because in the product team, things like this do not really happen... and if they do, that team would not last very long. In my case, I happen to be in the product team but forced through circumstances to work with the Windows OOB service organization...
  
  //David