Things People May Not Realize About Building Vista

I woke up this morning to find that Frank Arrigo had pointed to a post by Gary Wisniewski regarding "Microsoft's New Win-Win Strategy". The four components of Gary's proposal are:

1. Scrap the Windows codebase forever.  Release Vista, and announce publicly that it will be the last version of Windows based upon the NT/Win32 platform.
2. Use Linux as the base operating system for the next generation of Windows.  Do not modify it, do not "Microsoftize" it.  Do not try to own it.  Exploit it.
3. Reinvent the Desktop.  Call it Windows.  Windows: The Next Generation.  Outdo Apple, outdo the current platform, outdo every "Linux desktop" effort in existence.
4. Put applications first.  Office TNG, Project TNG, Excel TNG, Outlook TNG.  Do not port.  Rewrite.  Do not create a Win32 compatibility layer.  Do it right.

Gary mentions in his post that he plans to follow up with a series of shorter posting explaining each of these in detail, so I'll hold off on most of my thoughts until I get a chance to see where he is coming from. This isn't the first time I've heard these ideas--when I used to brief execs from tons of companies (almost daily) on the Longhorn Vista plans, they often had ideas like these. After the first few dozen, I discovered that there is actually a short list of points people disagree on (or haven't thought through) that are critical to any reasonable debate about the future of Windows (or any other gigantic effort):

1. You can't estimate how long it will take to complete Windows (or any other humongous project). Regardless of what tools, people, and experience you apply, it's simply impossible to model a system like Windows, especially when you have to consider the butterfly effect that occurs every time a dev in RPC gets sick for a week. The "slips" in the schedule aren't due to engineering incompetence or lack of motivation, they're simply timequakes that occur when the organization acknowledges the need to recover from an overly aggressive schedule estimate.
2. You can't trick a development team into shipping on time by publicly overestimating a schedule. People always cleverly offer this advice when they've never been part of a product development cycle. There are two forces at play here. First, work will always expand to consume all available time (this was "discovered" by someone more clever than myself, but I can't find a link). Second, marketing-driven schedules (these are schedules marketing people define while the development team is still too busy shipping the previous version to pay attention to) tie into market needs and not engineering costs. As a result, each team ends up deciding what they can build based on what time they have and what the other teams are building. Teams often make a bet that another team can deliver a platform technology that they plan to leverage for their features, so when those fall through, they're stuck figuring out what they should do with the investment they've already made.
3. Windows is the best operting system ever. Caveats? Of course. Every time you make a claim like this, some guy will show you the Furby embedded system OS and explain why it's so much better for Furbies than Windows is. As a result, it's necessary to say "Windows is the best mass market operating system for clients and servers due to its reliability, scalability, performance, usability, documentation, application support, hardware compatibility, billions of already-trained users, and total cost of ownership". People who ask broad questions like "why doesn't Microsoft give up like Apple did and just adopt a better OS like *nix?" don't recognize how good Windows really is. I know I'm leaving this bullet very barren of supporting documentation.
4. Experienced users want to use the OS and apps they're experience with. Once again, there are caveats about Mac/Linux/whatever zealots who will always rebel against the idea of using Windows. But the plain fact is that most people who know Windows want to use Windows because they already know how to do the things they need to do. The same goes for applications like Office, etc. Every time someone says that Microsoft should scrap Windows or Office in favor of a brand new look & feel has never had to support 50,000 desktops of 9-5 users who are simply working for the weekend. If you use a PC because you love to use a PC, then you're more likely to have an emotional attachment. Otherwise it's as mechanical as using your CD tray as a coffee mug holder.
5. Application compatibility is critical. This may seem obvious to everyone, but it's always worth saying. Every time an XP app fails to run on Vista, a puppy will be shot from a cannon. Sadly, there will be many airborne puppies. Right now people are tearing their hair out dealing with UAP (where an admin isn't really an admin) and I'm seriously concerned with how it will impact perceptions of Vista when it ships. Even broaching the subject of scrapping a platform and breaking every app altogether is a surefire recipe for disaster of epic proportions. Not only would it destroy Microsoft as a company for a long time, it would have economic ramifications across the globe from IT departments who didn't plan their migrations well enough for such an ill-fated deployment, resulting in hospitals losing power, planes falling from the sky, wine turning back into water, and all dolphins leaving the planet once and for all.

To be clear, I'm not disagreeing with Gary just yet because I don't understand where he's coming from. However, I do have a feeling the issues are important to the four points he makes. It's also important to note that the points I've made don't map 1:1 to the points Gary makes and that they are not prioritized.

Oh, and I might decide to change the text at any time, so if you post a flame, I might reword the bullets to make it seem like you're disagreeing with something you actually like.

5/29/2006 10:42:05 AM (Pacific Standard Time, UTC-08:00)      Comments [1]  

Expedia Impresses The Heck Out Of Me

I never thought I'd actually see something like this:

I guess I must be jaded, but it's awesome to see a company save you money like this. After all, I would have ended up paying the extra $16.68 for each ticket without thinking twice, so this was money they're leaving on the table, unless they think I might end up going somewhere else to save a few bucks.

I'd probably feel much different if I was a shareholder

5/28/2006 2:47:37 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Changing Your Visual Studio 2005 Source Control Plug-in

I recently installed Team Explorer on a machine that also had Visual SourceSafe 2005. To add a new solution to my TFS server, I right-clicked the solution in Solution Explorer and selected "Add Solution to Source Control...". It kept popping up the VSS enlistment UI, which was aggravating. Sure enough, under the Tools | Options menu you can change Source Control | Plug-in Select to "Visual Studio Team Foundation Server" and it'll use that plug-in instead. I assume you can switch back and forth as needed. It might seem obvious to everyone else, but I figured I'd post it anyway to save time for googlers.

I wonder if it's possible to have VS use multiple plug-ins simultaneously without killing the user experience. My guess is "no" since it wasn't done, but maybe something sweet will come up in the next version.

5/28/2006 2:28:25 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Microsoft's New Employee Performance Rating System

After speaking with some folks involved with the recent town hall meeting and reading up on the resulting blogs and articles, I'm kind of surprised at reactions from key bloggers like mini and Scoble. I'll start off by caveating that I have not personally reviewed the new policies, but am making observations based on published materials from the sources I trust listed above.

I understand the happiness over things like bringing the towel program back. I never used them and never noticed them being gone while I was an employee. Still, if I had grown to take something for granted, I'd be happy about getting it back after it was taken.

However, I'm surprised about the happiness over stack ranking and the new comp model. First, my understanding--which may be off base--is that the model is aimed only at improving the benefit to the top performers. From my experience, these weren't people who had morale issues, so I can only believe this model was intended to stem the flow of brain drain.

Regarding the stack ranking, it's definitely not going away. Prior to the change, you roughly had:

1. 4.5-5.0: Rare
2. 4.0: 20%
3. 3.5: 37.5%
4. 3.0: 37.5%
5. 2.5: 5%

Although my experience was relatively limited, I found several things common about these rankings:

1. 4.0+ people are never disappointed and have high enough morale not to complain about morale
2. 3.5 people are almost always disappointed and feel they were barely passed over for 4.0s
3. 3.0 people are disappointed because they feel they're borderline 2.5, except for the handful who received 3.0 due to a recent promotion, group change, asking for permission to interview, etc (they all hate this practice)
4. 2.5 people are not surprised because they already know they should be looking for a new job

People might debate the observations above, and I'll concede the admittedly small sample size I'm working with.

The stack ranking is now:

1. Outstanding: 20%
2. Strong: 70%
3. Limited: 10%

I'm sure that each manager will be still required to stack rank their team, and then pass their proposed stack up the management chain. At some point, the stack will be finalized, and each person will get their result and the comp that is tied to it.

So what's the difference?

When most people land in "Strong", it'll be very easy for management to play up where they landed. In effect, the system has become pass/fail with the occassional "honors" thrown in to motivate the top 20%, along with better cash, stock, etc. Hopefully this will work in their favor by having a much more content majority of non-stars and let the handful that are deemed above the grade to remain in the company.

The one thing that people shouldn't say is that the system has changed because it really hasn't. Some numbers have gone up and others down, but in the end you just get less information about your performance than before from the overburdened management, which is probably better for everyone concerned.

5/21/2006 1:00:13 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Setting Expectations And Being Accountable

I came across this posting tonight, via Scott Hanselman's riff on it, and it really got me thinking. In a nutshell, the postings talk about how life has changed over the past decade or so due to the broad acceptance of new technologies (email, voicemail, DVRs, RSS, etc), resulting in increased pressure on people to act on information as it becomes available, lest it pile up ominously.

I'll readily admit that I've often found myself in the past to be behind by a few voicemails, a few tens of DVR hours, a few hundred emails, a few thousand RSS items, etc. In fact, I'll bet most people feel the pressure to act and react to their open channels every second on a daily basis. However, I feel I've managed to find a pretty useful solution to this problem: saying “no” early and often.

Don't get me wrong--if you send me an email that expects a response, you'll get it. If I record TV I want to watch, I will. If you leave me a voicemail, I'll call you back. I think that saying "no" is a critical skill, but one that must be used preemptively.

At SharpLogic, I take on many different responsibilities that sometimes have complex interdependencies and are almost always "important" or "critical" (8+ on a 10 point scale). Every day I find myself with more than enough work to do, and it seems like there's always a ton of projects in the pipeline, which range from customer engagements to network maintenance to accounting to recruiting and so on. Some responsibilities are more important than others. However, every responsibility is still necessary.

One common thing I hear from people is "if I didn't reply to your message from last week, resend it because I delete all mail that's 10 days old". While this attitude may be fine among friends, it's completely unacceptable to a client.

Clients come to us with problems they need solved. In most cases, the problems range beyond software design to require a marketing perspective, and they also often necessitate a level of business consulting. They have tight deadlines (sometimes extremely tight) and, of course, need high quality results.

Sure, this might all sound common, so why do they come to us?

Results. I like to think of SharpLogic as Harvey Kietel’s character Winston Wolfe from Pulp Fiction (if you don’t know who that is, go see the movie).

When someone approaches us, they’re not looking for implementation of a spec. There probably isn’t even a spec. In fact, there probably isn’t even an identified solution. Clients come to us with problems—problems they want to “go away”. They want someone else to think about the problem, analyze the options, determine the best course of action, and deliver a proposal that minimizes the amount of time and effort they need to invest for the results to be delivered. The last thing they need from us is to be filling up their voicemail and email inboxes with tons of micromanagement administrivia. If we’re putting them in a position to say “no” to our requests, we’re part of the problem to begin with.

I know this is starting to sound like a commercial for the company, but I actually do have a point: I say “no” a lot.

In order to ensure our ability to deliver for customers, it’s necessary to be sure we have the time and resources available. If we don’t have time and resources, we won’t take on the project. There’s nothing worse than saying “no” to a customer after you’ve said “yes”—so avoid the problem by undercommitting, underpromising, and overdelivering.

These days my inbox rarely exceeds 25 “action required” items. I occassionally get voicemails, but they're usually some Silicon Valley startup trying to get me to resell their SharePoint Pong clone. Overall, it’s actually very easy to stay on top of everything if you scope “everything” down to a manageable size.

On a related note, I used to always wonder why people who are always “slammed” (way behind in work) ever got promoted. Then it occurred to me that the easiest way to undercommit, underpromise, and overdeliver is to always say you’re slammed. While I understand the motivation, it’s never been a strategy I’ve felt comfortable with since it lowers the confidence your peers have in you. However, it is an interesting, somewhat Darwinian, evolutionary mechanism that evolves the modern information worker. It’ll be interesting to see how it works out.

If you find yourself constantly slammed, you need to ask yourself whether or not you're overcommitted. I wish there was an easy formula to figure this out, but there isn't. While it would be great to get Outlook to automatically delete emails you'd end up deleting anyway, perhaps a better solution is to figure out why you're getting those emails in the first place. Sure, there's always unavoidable spam (both anonymous and from people who should know better), but there is also a level of personal accountability required to resolve the disease, not just the symptom. Sometimes people overcommit without realizing it (like the 35 Futurama episodes on my Media Center) or have a passive aggressive need for control (100+ RSS subscriptions ). Being overcommitted is awful and doesn't help anyone, especially those who rely on your committments only to have them broken.

5/17/2006 1:01:26 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Our LEGO Project Mentioned On CNET

http://news.com.com/Microsoft+extends+tool+giveaway/2100-1007_3-6062716.html?tag=nefd.top

For everyone who emails me weekly asking if it's available yet, the answer is now "yes".

If you decide to play around with it, be sure to read John Wingfield's tips & tricks paper that will help you stay sane if you run into any problems getting things set up. Pay extra close attention to the infrared section as it just may save your life.

We really pushed the limits of the integrated ("tethered") programming model for the MINDSTORMS, so there are some things that might seem non-intuitive when you look at the library source. One of these days I hope to write a post about some of the major challenges we had to overcome, as well as the optimizations that make it usable. The library isn't right for every LEGO programming scenario, so take a look at the capabilities of MindScript and other "autonomous" offerings when picking a solution. If your solution needs to interact with a PC (such as to track a movement map or receive user input) then I think this project is the best solution available.

4/19/2006 10:32:01 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Quick & Dirty x64 Porting Fix

I've been porting a native app to x64 (64-bit Windows XP) and having some headaches. In particular, I was running across this error:

This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem.

Ironically, the app in question was part of the install process, so it definitely wasn't an installation issue.

After a few unsuccessful minor tweaks, I ended up creating a new "Hello World" app with VS 2005 on my 32-bit dev tablet. Sure enough, I got the same error when running it on the fresh 64-bit. After a little investigation, I found that I was able to run the app by not embedding the manifest (set "Embed Manifest" to "No" in Configuration Properties | Manifest Tool | Input And Output of the app's properties dialog), which is done by default.

I wouldn't recommend using this as a basis for a port, but it can help you get the app up and running quickly.

4/12/2006 8:44:20 AM (Pacific Standard Time, UTC-08:00)      Comments [2]  

I Can't Leave For A Single Week?!?

I was in Beijing last week, and look what happened while I was gone:

Ashton, am I being punk'd? Anyway, if I see Tom or Katie, I'll ask where your car is.

4/12/2006 2:50:17 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Top Ten Most Annoying Recorded Messages

There are few things I've agreed with more than this list: http://www.vocalabs.com/resources/blog/C1672660030/E20060403162858/index.html.

4/4/2006 9:34:34 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Team Hanselman and Diabetes Walk 2006

Scott gives a ton to the community (such as being lead dev on DasBlog [the app that runs SharpLogic's blogs] and chairing the Portland Code Camp). If you can, help him out: http://www.hanselman.com/blog/TeamHanselmanAndDiabetesWalk2006.aspx

3/20/2006 12:00:23 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

The Tale of Two Jimmys

Scott brings up some good points about the future of America: http://swigartconsulting.blogs.com/tech_blender/2006/03/h1b_visas_and_t.html. I love "HIS NAME'S NOT JIMMY!!! THERE ARE NO JIMMY'S IN CHINA!!!"

While I completely agree with Scott regarding the number of no-ops our country regularly produces, I also have a great deal of confidence in the future thanks to programs like H1B, which continually raise the average IQ and work ethic of our workforce and genepool. For the record, the H1B process makes sure you've given US citizens a fair opportunity to take on the job and requires you to pay the prevailing wage for a region, so it's actually more expensive to hire using H1B (after you account for legal and filing fees).

However, if we could also export one dud for every rock start import, that would be great too.

3/20/2006 11:32:24 AM (Pacific Standard Time, UTC-08:00)      Comments [0]