News

Transparency run amok

• By Mike Gunderloy
• June 25, 2004

Microsoft-watchers have been speculating recently on when we'd see the next beta of Whidbey (Visual Studio 2005) and Yukon (SQL Server 2005). Such watchers got an unexpected treat this week when VDT Status Update Whidbey 06/24/04 appeared on the weblog of the Visual Studio Data Team. This is, straight from the development team at Microsoft, a copy of the weekly report for this particular portion of the Whidbey development team. It contains information on the status of the current build, the number of open bugs against beta 2, overall status notes, and so on. From this single page, you can divine some interesting information (such as the fact that Whidbey beta 1 will be frozen before Yukon beta 2) or just lose yourself in a host of acronyms. Some, such as SxS for "Side by Side" are fairly easy to sort out; others (OGF?) remain opaque to me.

Although a later weblog entry makes it clear that this status report was at least somewhat redacted for public consumption, it still represents an unprecendented level of opennesss from Microsoft. To put this in perspective: I've been a participant in several extremely tight alpha test programs for Microsoft software, and we were never able to get such status reports for those programs shared with non-Microsofties, try as we may. Now at least one brave team appears ready to share the status with the entire online world.

To be honest, I'm not sure what to make of this. On the one hand, it's nice to see the product teams experimenting with keeping us better informed of what's happening. This can only help those who depend on Microsoft software make better plans for the future. Knowing which products were where in the release cycle, for example (instead of vague "beta in May or June, or maybe July or August" promises) would help us allocate resources to testing when it made sense to test, and to know which products we could depend on when.

But I can see some potential downsides here too. For starters, development teams at Microsoft generate a lot of paperwork (well, webwork, these days). If every team I was interested in started putting all of their status reports, specs, schedules and so on out on the Internet (instead of keeping them on Microsoft's intranet) I'd be overwhelmed trying to keep up.

And what would happen when management takes note of that burst of activity? It's easy to imagine that some of the senior people at Microsoft might thing that this was a little too much transparency, and try to get the product teams to pull back. It wouldn't surprise me to see a head or two roll at some future point, as Microsoft's business and the natural tendencies of its developers to want to talk about what they're doing collide.

Suppose management were to decide to impose reasonable limits on the bloggers? I can see perils there too. It's easy to imagine how carefully-crafted status reports, with selective information removed, could be used as a tool to mislead competitors or to keep customers on the hook for future versions. Done with enough guile, this could turn into a new version of the same old FUD tactics that used to take place over beer at trade conferences. One likes to think that Microsoft has learned not to stoop to such things, but it's hard to be sure.

Of course, the other thing that could happen - and that I hope happens - is that Microsoft could take the bold step of institutionalizing this practice. Imagine a web site, call it statusreports.microsoft.com, devoted to posting information on Microsoft's progress on various next-generation software. You could select a product and then view the most recent status report, or flip back to previous weeks. There would be cross-linking between teams, so that if you didn't know what the Komodo grid was you could look it up. There would be a glossary of acronyms somewhere. And somehow, there would be a set process for making sure the level of transparency was reasonably constant across the various teams.

If such a thing were to come to pass, it would be great for the average developer trying to keep up with Microsoft. It might be bad for those of us who make part of our living trying to analyze the latest Redmond rumors. But don't worry about us; we'll find something to keep writing about in any case.