And you know, speaking of The Commons: I trekked over there today (meh, not the sunniest day) and I have to say it's an impressive space. I walked around admiring the scope of the project, thinking "This is what Windows built. This is what Office built." I then reflected on the irony that it's Mr. Robbie Bach's Entertainment and Devices moving into the new campus with The Commons. Windows and Office funded this extravagant place for the folks who managed to burn through $8,000,000,000USD+ on the Xbox, be shown how it's done right from Nintendo with the Wii, dash the Zune against the juggernaut iPod, and have the iPhone drop-kick WinMobile to Mars.

On a good day, I can convince myself that these are important businesses to be in, and we can afford to lose money to be successful in these business.

Most of the time however, I just try to happily enjoy my XBox 360, Zune, WM6.5 (beta) phone, Media Center, and beautiful keyboard, and try to ignore the fact that I’m paying for all of those products via my stagnant stock (and my nearly 10 years of work on Servers, Windows and Office – all extremely profitable businesses that are funding that E&D campus).

So, thanks for the nice products, E&D. And, you’re welcome.

]]>https://blogs.msdn.microsoft.com/justsean/2009/04/23/ah-irony/feed/0Someone has an interesting view of PMs (at least at Yahoo!)https://blogs.msdn.microsoft.com/justsean/2009/04/22/someone-has-an-interesting-view-of-pms-at-least-at-yahoo/
https://blogs.msdn.microsoft.com/justsean/2009/04/22/someone-has-an-interesting-view-of-pms-at-least-at-yahoo/#commentsWed, 22 Apr 2009 05:43:23 +0000https://blogs.msdn.microsoft.com/justsean/2009/04/22/someone-has-an-interesting-view-of-pms-at-least-at-yahoo/I’ve often gotten the idea that a Yahoo! Product Manager is more or less the same as our Program Management. Their new CEO, whose attitude I like (she happily discourses on the things she thinks are ridiculous about their products – something that she’ll start to stop doing once stuff is built under her), seems to have a proverbial bee in her proverbial bonnet about (at least some) Y! product managers. From their Q109 quarterly earnings call:

“We sort of had one product management person for every three engineers. So we have a lot of people running around telling people what to do but no-one is f**king doing anything. [apology]. The point of the matter is first we’re getting all of the engineers, like, on the same page; we’re getting rid of a lot of those product people that, you know, whatever.”

First, I’d love to talk to the person who has to generate the transcript for that call. That cursing is now filed for eternity with the SEC. Second, good for her recognizing that there are too many PMs running around doing basically nothing.

In my ongoing search for “truth and enlightenment” when it comes to the PM job, it’s been very clear to me that Program/Product management is one of those jobs in which the PM can be basically irrelevant. Even more problematic, the PM can easily be a hindrance to the running of the project.

To the first point, there is fundamentally only one job discipline that is irreplaceable in a software development, and that’s the one that types the braces, semi-colons and/or angle-brackets. If your job does not involve doing that, then your job is not critical. PM, for the most part, does not involve coding. So PMs, are, by definition, extra weight.

To the second point, the PM occupies a unique position in most software engineering structures – sort of the hub of a bumpy wheel (with dev, QA/test, design, usability, marketing, planning, customer support, etc. being the spokes). The PM at that position can wield a lot of influence, but can also slow things down, create confusion, and can also basically become pompous little buggers.

I often ask PMs to remember the first part, to create some humility, and the second to create a sense of responsibility.

Ultimately, the combination of these two failure scenarios for PMs means that many, many PMs fail while still on the job. In short, a PM who suffers from the second problem will be sooner or later relegated to irrelevancy by other spokes of the wheel. But since they probably still run around producing good PowerPoint decks, their irrelevancy will not be noticed by the management of the organization.

At least until a new Sheriff rolls into town with different ideas.

]]>https://blogs.msdn.microsoft.com/justsean/2009/04/22/someone-has-an-interesting-view-of-pms-at-least-at-yahoo/feed/1Castle and HomeGroup: A study in the evolution of user needshttps://blogs.msdn.microsoft.com/justsean/2009/01/16/castle-and-homegroup-a-study-in-the-evolution-of-user-needs/
https://blogs.msdn.microsoft.com/justsean/2009/01/16/castle-and-homegroup-a-study-in-the-evolution-of-user-needs/#commentsFri, 16 Jan 2009 05:34:54 +0000https://blogs.msdn.microsoft.com/justsean/2009/01/16/castle-and-homegroup-a-study-in-the-evolution-of-user-needs/Several years ago, at the beginning of the “Longhorn” project (which eventually became Windows Vista), I worked on a project that was attempting to solve the problem of how to make file sharing in small networks (particularly at home) both simple and secure – something that, frankly, Windows has been working for a long time.

I worked with a small team of architects from across Windows to develop a technical concept that was eventually codenamed Castle†. Castle eventually became a fairly major project in Longhorn. Details of this project have trickled over the years, but since it never shipped in any usable form, it’s not widely known or understood, though some have tried to figure it out.

The Castle idea

Castle was based on the idea of creating a small network (typically in a home environment) with a shared concept of user accounts. In typical home networks, the main gating factor in a simple, secure sharing model is that the PCs each have their own idea of the users – a user on one PC doesn’t even “exist” on the other PCs. Earlier versions of Windows have approached this by having a password-based sharing model (the user create a password, and tells it to other people who want to get stuff from their PC), or having a completely open sharing model (put something in a particular folder, and anyone on your local network can get to it).

With Castle, the user accounts were shared with all PCs, with changes made to the user account information on one PC replicated to the other PCs automatically. A user on one PC could share pictures with the other members, and, using standard permissions model, make decisions about who could see what. Any single user could also log on on any of the other PCs using their own account (with replicated settings, of course). The advantage of this model from a technical perspective was that it would take advantage of all of the security and file sharing features that users in a corporate domain have used for years.

The interesting* thing about Castle, however, was that it was built around a model of home networks that assumed that, for the most part, home PCs were shared by users in the home. At the time (early 2002), home networks were uncommon, but were growing in usage, but typically, they were an extension of the home PC – two or three PCs shared by the users of the home, occasionally with one or more them primarily used by one person.

On HomeGroup

Contrast the model of Castle with this description of observations from the HomeGroup post on the Engineering 7 blog:

A majority of the computers in our panel only had one primary user. While we all know that laptop sales have overtaken desktop sales in the last couple of years, this data tells us that people are buying PCs more for specific people rather than for a shared location [emphasis mine].

HomeGroup is solving the same things that Castle was trying to solve – simple and secure sharing of documents, media and devices. But, this simple shift in the dynamics of home networks from shared PCs to single-owner PCs suggests a change in the solution. Instead of attempting to create a shared concept of user accounts, HomeGroup assumes a network of “equals and peers”, and uses the concept of a single shared password (a well-chosen analogy in the E7 blog compares this to the concept of the front-door key in a home) to build a trust relationship between the home PCs on top of which the media sharing, libraries and search features are layered.

Evolution of ideas

Some have postulated that HomeGroup is basically dusting off and shipping Castle. I’m not part of the team building HomeGroup (nor was I part of the Castle team at the end – I had switched focus to Wireless and Bluetooth projects and handed off the project to another team), but the Castle project ultimately died as a victim of the Longhorn reset in 2004 – at its height, it had grown to be a joint project of at least four different Windows teams. Like HomeGroup and its integration with Win7 technologies, Castle had pieces that depended on WinFS and other Longhorn technologies that never shipped in any form. It’s highly unlikely, given the different fundamental directions of Castle and HomeGroup, that they share any code.

In a world of single-owner PCs, Castle would, frankly have been overkill. If Castle had existed, the current HomeGroup concept could have been built on the base framework, but instead, like much of Windows 7, HomeGroup is a simpler, easier-to-use solution to the same fundamental problem Castle was trying to solve. HomeGroup was most likely built from scratch and integrated with other Windows 7 concepts and technologies (NLA, Libraries, Media Player sharing).

What the Castle and HomeGroup projects ultimately did share was the desire to make home sharing simple and secure‡ that Windows teams have been trying to solve for years. I don’t have enough PCs with Win7 at home yet to fully try out the HomeGroup feature, but from everything I’ve seen, the team seems to have delivered a simple and effective solution to the problem we set out to solve over six years ago.

Windows 7 seems to be, yet again, living up to the promise of Windows Vista.

/fin..

† On naming: One early set of notes I still have that was written by one of the technical architects, Richard Ward (currently a Microsoft Distinguished Engineer in the Windows Core Architecture group), used the term “Minidomain.” I toyed with the codename “dominion” -- a play on “mini domain” – but it didn’t really catch on. The idea for the final codename originated with Andrew Sinclair, the GPM of my team at the time (currently General Manager of Hosted Exchange) and one of the inventors of the Castle concept, who opined, in his typically British way, during brainstorming, “A man’s home is his castle.”

I wrote most of the early scenario documents related to the project (used to flesh out and sell the concept), which made it easy for me to be the one to choose the codename. I latched onto the word “castle” from Andrew’s quip, which worked since it had the same medieval echoes of its technological ancestor, the Windows Server domain (a domain is a Windows enterprise concept of centrally administrated network systems). It was also a perfect analogy for what we were trying to build – a wall of protection around a set of PCs.

As a side note, we did spend quite a bit of time brainstorming with marketing about a branded name to use in the product. I had a moment of panic when, in one of these meetings, the marketing team got quite excited when I jokingly tossed out the name “workgroup .net” – the term “.net” was making the rounds in the company as the popular term to add to things, and Castle was, as HomeGroup is, an evolution of the long-existing idea of a workgroup. I think we can all breathe a sigh of relief that the “.net” fad has run its course.

* There were plenty of interesting things about Castle, for what it’s worth. Castle was, as was typical of Longhorn-era projects, quite ambitious. In my first scenario documents that I used to popularize the idea around the company, I had designs not only for simple and secure file sharing (the primary goal), but also for ways to potentially revolutionize concepts like application installs (install an app on one PC, and, via the secure mechanisms we were developing, we could replicate the application and its settings to the same user account on all of the PCs in the home, making it easy, as a user to move from one PC to another – obviously this would have required changes to the way apps were licensed, but we had a number of ideas for how to, for example, allow a user to use the app on only one PC at a time). I talked with the Windows Update team about using the Castle framework to distribute patches within the home after one system downloads them (patch distribution has be done via a secure distribution because systems basically install them automatically, so if someone can insert bad code that would be a bad thing). I also spent some time with the media player DRM team on techniques to automatically license downloaded music to all PCs in the home. We didn’t really plan to ship all of this in Longhorn, but we wanted to to lay a foundation for building features and applications in future versions of Windows that could rely on a secure, trusted home network.

‡Simple and secure – I harp on this phrase, because it’s relatively straightforward to make home sharing simple, and other products have made strides in that direction. It’s also easy to make home sharing secure – just lock everything down :). It’s a real challenge to bridge both concepts.

]]>https://blogs.msdn.microsoft.com/justsean/2009/01/16/castle-and-homegroup-a-study-in-the-evolution-of-user-needs/feed/1Impressive effects in PowerPointhttps://blogs.msdn.microsoft.com/justsean/2008/12/12/impressive-effects-in-powerpoint/
https://blogs.msdn.microsoft.com/justsean/2008/12/12/impressive-effects-in-powerpoint/#respondFri, 12 Dec 2008 04:17:48 +0000https://blogs.msdn.microsoft.com/justsean/2008/12/12/impressive-effects-in-powerpoint/Not too long ago, I joined the PowerPoint team. Thought I spend most of my time working on a related project, I do spend a lot of time working with PowerPoint itself, and I’m constantly amazed at the things that people do with PowerPoint.

Recently, on the PowerPoint blog, Ric posted an entry about a series of new template documents that show you how to create amazing and useful effects in PowerPoint 2007 created by one of our MVPs, Julie Terberg.

With regard to where ideas come from, what we like to say is that the job of program management is not to have all the great ideas but to make sure all the great ideas are ultimately picked. The best program managers make sure the best ideas get done, no matter where they come from.

A nice formulation to add to my various other definitions of Program Management collected over the years.

]]>https://blogs.msdn.microsoft.com/justsean/2008/10/23/the-job-of-program-management/feed/0Little things you may not have noticed in IE8: Part 7 – Stop and Refresh buttonshttps://blogs.msdn.microsoft.com/justsean/2008/09/11/little-things-you-may-not-have-noticed-in-ie8-part-7-stop-and-refresh-buttons/
https://blogs.msdn.microsoft.com/justsean/2008/09/11/little-things-you-may-not-have-noticed-in-ie8-part-7-stop-and-refresh-buttons/#respondThu, 11 Sep 2008 11:05:00 +0000https://blogs.msdn.microsoft.com/justsean/2008/09/11/little-things-you-may-not-have-noticed-in-ie8-part-7-stop-and-refresh-buttons/Move stop-and-refresh back to where they were in IE6

This was going to be my first post in this series, but the Vista Team blog stole my thunder with a muchmore detailed post covering lots of the chrome customizations, so I left it for last. Be sure to check it out the Vista blog.

PS. A quick reminder: I don’t work on IE, and I haven’t for nearly a year. So this all qualifies as my personal opinion, and not the opinion of the IE team. I found all of these feature just by playing around with IE (okay, well, some of them I knew where to look -- but I didn’t necessarily know they had made the final release)