A few weeks ago, IE7 suddenly slowed down on my main PC. Each time I'd start it up, IE7 would take several seconds to get past the "Connecting..." message, meanwhile leaving me staring at a blank window. Once I got to the first screen, performance improved, but occasionally clicking a link would produce a 404 error and I'd have to click Refresh to display the page.

At first time I didn't have time to fool with it, especially since I was spending most days on the road with my laptop, where IE7 was still running normally. But when I sat down at my PC Monday morning, launched IE7, and waited 10 seconds or so for the page to appear, I really got steamed.

After verifying that certain features such as the phishing filter were turned off, I began disabling add-ons one at a time. Sure enough, the culprit came to light: The Windows Live Sign-In Helper. Disabling it using the Tools->Manage Add-Ons menu got IE7 running normally again.

I don't even know when that add-on was installed, but it sure is frustrating when an add-on from the same company that produces the browser makes the browser run in slow motion. If I was the IE team, I'd be ticked.

Installer SDK, and we decided to try out value-based pricing as a social experiment.  Our thinking was that developers make their living - and typically a more comfortable living than flipping burgers - and that the would a) understand the value of code and time saved and b) be willing to compensate us for the SDK based on their perceived value of the product.

We here we are a full four months later, and how is this experiment going?  Well here's a graph that says it all:

What this says is that we've sold 51 "value units" to 37 customers, meaning that over 80% of you who bought it only paid $5.  Now assuming you're a low-paid, entry-level guy making only $40k a year that means you felt it's worth just over 15 minutes of your time (and keep in mind this thing comes with full source code).

What this tells me is that one of these must be the case:

1) The SDK sucks and has no value
2) People don't understand "value-based" pricing
3) Developers are cheap bastards who will pay as little as possible for something

Well #1 is probably not true, as we've used it on a few projects and it works well.  I think we descibed value-based pricing pretty clearly, and it's not a tough concept.  So all I can conclude is, well, #3 must be true.  Now we can't really hold it against you, after all we did allow you to buy it for $5 and some people simply have low moral standards.  I'm just surprised it's so many of you.

Will we change the pricing model?  Well I have two thoughts on that.

1) the current pricing includes zero support, so it's no "work" for us to just leave it as-is
2) moving it to fully open source might increase the number of people using it

I'm inclined to go with #1, simply because moving it to open source requires a bit of work on our part.  In short, we'll keep it out there as an apparent $5 product because I'm too busy to do anything else with it, but the likelihood of it getting any additional features is pretty slim.  It was an experiment that yielded data, and as such I'd say that it was valuable.  It certainly shows that it's a pricing model that can't be used to support a business.

  We're building a backyard shed, and I recruited a certain young teen to help. Sooner
  than I expected, he was back inside the house. "Finished already?" "I need a rest."
  But I only see two or three pieces of wood carried from the under-roof storage area
  to the work zone. It turns out that he kept bringing the wrong piece of wood (2 x
  4 when asked for 2 x 6, or 8 foot when asked for 10 foot) and having to take it back
  and go get the right one. This is tiring, of course. But I also found it illuminating
  because a similar thing happens with my new hires who are straight from school or
  university.

In an academic setting, if I assign you the task of getting me a 10 foot 2 x 6, and you bring me a 10 foot 2 x 4, or an 8 foot 2 x 6, I will probably give you a pretty good mark. Not 10/10, of course, but at least 7. After all, you have brought me wood, as opposed to a rabbit or some mashed potatoes. You have come back with something, rather than wandering off into the woods to play or inside to watch TV. You have even got one of the dimensions right and the other close to right. So you receive your mark and you're done. Similarly when I mark a programming assignment, maybe I spot a logic flaw or other mistake, your code won't work under certain circumstances, but it works some of the time, or almost works, or at least doesn't always blow up. I can give you 7/10.

In the real world, whether of shed building, or code writing, things are more binary. I have the wood I need or I do not. Your code meets our standards or it does not. And here is the key thing - you have to make it right. Take this wood back and bring a longer piece, or a wider piece. Take this code back and make it so it can accept strings with apostrophes in them, or so the title is centred, or whatever other bug you need to fix. You're not done until it's right.

It's a lesson that probably needs to be taught more explicitly to the new grad. It wouldn't hurt to teach it a bit in those academic settings.

Kate

User-agent: zombies
Disallow: /brains

Google's robots.txt...

[Thanks Hebbet!]

[By Tony Ruscoe | Origin: Google's Robots.txt Halloween Entry | Comments]

[Advertisement] Google books at eBay: background info on Google, AdWords, AdSense, Blogger and more...

Every job has its quirks. That?s what Kirk reassuringly told himself on his first day of work after meeting the company?s most egregious quirk, The Colonel. Kirk wasn?t quite sure if the impeccably-dressed man?s gruff introduction ? which solely consisted of looking Kirk up, then down, then up again, and scoffing ?that?s a pretty sad excuse for a Double Windsor? ? was in jest or contempt, so he stuck with a the more palatable label of quirky. Fortunately, by the time Kirk realized that deranged was much more appropriate than quirky, he knew that he?d never have to personally work with The Colonel: the chain-of-command simply wouldn?t allow for it.

Having spent the larger part of his life in the military, The Colonel faithfully chose the same rigid structure for his civilian venture, a technology start-up that developed real-time logistics tracking systems. The ?high-discipline? company worked well for the first year or so, as The Colonel had only hired ex-military employees and had only solicited to the military. However, when it came time to expand into the private industry, a few concessions were needed to attract the less-disciplined civilian talent: health benefits, sixty-minute lunch breaks, casual Fridays, etc. Of course, the company?s core values ? chain-of-command, strict rules, top-of-the-line accommodations for executives, and so on ? would never change.

A Good Problem to Have

When Kirk joined, the company was in the middle of ?a good problem to have.? Months earlier, the development team had created a prototype to demonstrate the company?s capabilities to prospective clients. Their prototype was pretty impressive for the time: using inexpensive GPS units, standard cell phones, and off-the-shelf server hardware, their system would track ?field assets? such as delivery trucks in real-time and display the asset on an interactive map.

As for their problem: The Colonel and his sales team told prospects that the prototype was their core product, and managed to sell a handful of licenses for it. Since putting more soldiers on the ground apparently solves all military problems, The Colonel employed the same tactic and nearly doubled the staff. With a company of fifty (half of which were developers), they were bound to successfully deliver the product they had sold.

But Still a Problem

As it turns out, developing a complex, customizable geographic information system that interfaces with an amalgam of less-than-ideal equipment is kinda hard. There are things like specs to consider, user interfaces to develop, equipment drivers to create, and so on. Add in to the mix aggressive deadlines, angry customers, and large refund checks to cut, and it creates something far worse than a ?good? problem. The immediate result of all this is one seriously angry colonel.

The Colonel knew very little about software development, software, and computers in general. In fact, he didn?t even have a computer in his office; his secretary was responsible for printing out his email and typing up his dictated replies. What he did know, however, was that computer programs are made up of computer code, computer code is typed up by programmers, and when programmers aren?t typing code, they?re not making computer programs.

To ensure that programmers were focused on programming, The Colonel cut out a lot of the unnecessary parts of the software development process like system design and testing. While the quit-wasting-time-and-type-in-your-computer-code approach certainly helped get more code written, there were a few side effects. Namely, their software didn?t quite meet the requirements and it was pretty buggy. The Colonels? new stop-writing-all-this-buggy-computer-code approach didn?t seem to help, either.

A Bad Problem To Have

After six long months of non-stop coding, development finally hacked together a system that could pass as the product sold to their clients. It kinda, sorta, somewhat tracked a variety of asset classes across a map, and usually displayed the results correctly. That is, assuming one was using the exact configuration of cell phones and GPS units that the development team had.

Unfortunately, the first client took the ?compatible with any receiver? feature literally, and bought completely different GPS units. While their system read the GPS data in, the coordinate system used was completely different, which meant that incoming GPS data piled up in the system?s processing queue. Changing the input filter on the cell phone fixed the incoming data, but there was still a mountain of bad data to deal with; and the customer really wanted the data fixed.

The Colonel was furious when he learned about this major glitch, and insisted that the problem be addressed immediately. There was just one caveat: since computer code caused the problem in the first place, adding more computer code would likely exacerbate the problem. They needed a solution that didn?t call for any programming to deal with the bad data.

Since the developers had absolutely no idea how to solve the problem without coding, The Colonel offered his solution: covert the data by hand, row by row. And he wasn?t joking; in fact, The Colonel never joked. The two developers assigned to documentation duty were relieved of that job and given an Excel spreadsheet and a desk calculator.

For nearly a week, the pair worked sixteen hours a piece, each day, typing in data from a print-off and calculating the results by hand. This effort did result in a fixed data file for the client, but also left two casualties: one of the developers quit, the other had simply lost all will to live. Things went a bit downhill from there.

Despite having two somewhat successful field installs, the company was not having any luck selling to other prospects. As the weeks passed, The Colonel was becoming more and more agitated that business was not picking up. So, he did the only logical thing and clamped down on all the slacking employees.

Cracking Down

The harbinger of many further disciplinary emails came after three employees had an impromptu meeting for a few minutes in an unoccupied conference room.

ATTN EMPLOYEES:

Effective immediately, no conference room may be used without first 
reserving the room on-line. We have a system for a reason and want
to make sure the rooms are utilized appropriately.

There are no exceptions to this policy.


DICTATED BUT NOT READ,
The Colonel

The next reminder came a day later after The Colonel spotted someone walking around with a cup of coffee and having a few words with someone past the time where everyone should be dutifully at their desks, slaving away:

ATTN EMPLOYEES:

Effective immediately, we will now be enforcing tardiness and desk 
policies. In addition, we will also be tightening up some of the 
attendance rules at the office:

1. WORKING HOURS. There shall be no more "thirty minute flex time". 
You are expected to be at your desk no later than at 8:00AM and 
leave no earlier than 5:00PM.

2. BREAKS. You have two fifteen-minute breaks and a half-hour lunch 
break. While you can combine your breaks, you may no longer "split" 
them and take five minutes, five minutes, etc.

3. DESK - When you are at your desk, you are expected to be working.

DICTATED BUT NOT READ,
The Colonel

The Colonel clarified these rules the next day.

ATTN EMPLOYEES:

There appears to be a misunderstanding of the attendance rules. You 
are to be at your desk, working, by 8:00AM and are expected to work
up at least 5:00PM. 

This means your computer must be turned on before 8:00AM, and you
need to pack your items up after 5:00PM.

DICTATED BUT NOT READ,
The Colonel

To no one?s surprise, the crackdown didn?t quite help morale or increase business in the least. It did lower expenses quite a bit; by the time this next email was sent out, twelve of the staff had resigned:

ATTN EMPLOYEES:

Effective immediately, we will no longer have "casual Friday." We 
don't stop working on Friday and should therefore dress for work.

DICTATED BUT NOT READ,
The Colonel

Over the next two weeks, another eight employees quit. By this point, The Colonel implemented some brilliant countermeasures.

ATTN EMPLOYEES:

Effective immediately, breaks may no longer be "combined". There
have been far too many employees abusing the break/lunch policy
and taking a full hour for lunch, each and every day.

Morning Break may be taken between 9:00AM and 10:30AM.

Lunch Break may be taken between 11:30AM and 1:00PM.

Afternoon Break may be taken between 2:00PM and 4:00PM.


DICTATED BUT NOT READ,
The Colonel

Obviously, through all these crackdowns, Kirk had turned looking for a new job into a full-time endeavor. Unlike so many other employees, he wasn?t quite comfortable just up and quitting without another job in the bag.

Of course, everyone has their limits. As it turned out, Kirk?s limit was this personalized email from The Colonel himself.

ATTN KIRK:

Earlier this week, you had brought in several large personal 
items and placed them in your workspace. You told your manager
that the purpose of this was so that your items "did not get
too hot during the day" in your car.

Please note that we are not a storage facility. Your workspace
needs to be clean and orderly; large personal items are not
acceptable. 

There are no exceptions, even if you need to store items just
for just one day.

DICTATED BUT NOT READ,
The Colonel

Kirk resigned shortly after that. While he tried his best to forget about The Colonel and the GIS system he had worked on, he verified that, four years later, they have yet to release their product.

A few months ago, Dare Obasanjo noticed a brief exchange my friend Jon Galloway and I had on Twitter. Unfortunately, Twitter makes it unusually difficult to follow conversations, but Dare outlines the gist of it in Developers, Using Libraries is not a Sign of Weakness:

The problem Jeff was trying to solve is how to allow a subset of HTML tags while stripping out all other HTML so as to prevent cross site scripting (XSS) attacks. The problem with Jeff's approach which was pointed out in the comments by many people including Simon Willison is that using regexes to filter HTML input in this way assumes that you will get fairly well-formed HTML. The problem with that approach which many developers have found out the hard way is that you also have to worry about malformed HTML due to the liberal HTML parsing policies of many modern Web browsers. Thus to use this approach you have to pretty much reverse engineer every HTML parsing quirk of common browsers if you don't want to end up storing HTML which looks safe but actually contains an exploit. Thus to utilize this approach Jeff really should have been looking at using a full fledged HTML parser such as SgmlReader or Beautiful Soup instead of regular expressions.

The sad thing is that Jeff Atwood isn't the first nor will he be the last programmer to think to himself "It's just HTML sanitization, how hard can it be?". There are many lists of Top HTML Validation Bloopers that show tricky it is to get the right solution to this seemingly trivial problem. Additionally, it is sad to note that despite his recent experience, Jeff Atwood still argues that he'd rather make his own mistakes than blindly inherit the mistakes of others as justification for continuing to reinvent the wheel in the future. That is unfortunate given that is a bad attitude for a professional software developer to have.

My response?

Bad attitude? I think that's a matter of perspective.

(The phase "programming is hard, let's go shopping!" is a snowclone. As usual, Language Log has us covered. Ironically, we later had a brief run-in with Consultant Barbie "herself" on Stack Overflow -- who you may know from reddit. There's no trace of her left on SO, but as griefing goes, it was fairly benign and even arguably on-topic.)

In the development of Stack Overflow, I determined early on that we'd be using Markdown for entering questions and answers in the system. Unfortunately, Markdown allows users to intermix HTML into the markup. It's part of the spec and everything. I sort of wish it wasn't, actually -- one of the great attractions of pseudo-markup languages like BBCode is that they have nothing in common with HTML and thus sanitizing the input becomes trivial. Users have two choices:

1. Enter approved pseudo-markup.
2. Trick question. There is no other choice!

With BBCode, if the user enters HTML you blow it away with extreme prejudice -- it's encoded, without exceptions. Easy. No thinking and barely any code required.

Since we use Markdown, we don't have that luxury. Like it or not, we are now in the nasty, brutish business of distinguishing "good" HTML markup from "evil" HTML markup. That's hard. Really hard. Dare and Jon are right to question the competency and maybe even the sanity of any developer who willingly decided to bite off that particular problem.

But here's the thing: deeply understanding HTML sanitization is a critical part of my business. Users entering markdown isn't just some little tickbox in a feature matrix for me, it is quite literally the entire foundation that our website is built on.

Here's a pop quiz from way back in 2001. See how you do.

1. Code Reuse is:
1. Good
2. Bad
2. Reinventing the Wheel is:
1. Good
2. Bad
3. The Not-Invented-Here Syndrome is:
1. Good
2. Bad

I'm sure most developers are practically climbing over each other in their eagerness to answer at this point. Of course code reuse is good. Of course reinventing the wheel is bad. Of course the not-invented-here syndrome is bad.

Except when it isn't.

Joel Spolsky explains:

If it's a core business function -- do it yourself, no matter what.

Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you're a pharmaceutical company, write software for drug research, but don't write your own accounting package. If you're a web accounting service, write your own accounting package, but don't try to create your own magazine ads. If you have customers, never outsource customer service.

Being a "professional" developer, if there really is such a thing -- I still have my doubts -- doesn't mean choosing third-party libraries for every possible programming task you encounter. Nor does it mean blindly writing everything yourself out of a misguided sense of duty or the perception that's what gonzo, hardcore programming types do. Rather, experienced developers learn what their core business functions are and write whatever software they deem necessary to perform those functions extraordinarily well.

Do I regret spending a solid week building a set of HTML sanitization functions for Stack Overflow? Not even a little. There are plenty of sanitization solutions outside the .NET ecosystem, but precious few for C# or VB.NET. I've contributed the core code back to the community, so future .NET adventurers can use our code as a guidepost (or warning sign, depending on your perspective) on their own journey. They can learn from the simple, proven routine we wrote and continue to use on Stack Overflow every day.

Honestly, I'm not that great of a developer. I'm not so much talented as competent and loud. Start writing and talking and you can be loud, too. But I'll tell you this: in choosing to fight that HTML sanitizer battle, I've earned the scars of experience. I don't have to take anybody's word for it -- I don't have to trust "libraries". I can look at the code, examine the input and output, and predict exactly what kinds of problems might arise. I have a deep and profound understanding of the risks, pitfalls, and tradeoffs of HTML sanitization.. and cross-site scripting vulnerabilities.

As Richard Feynman so famously wrote on his last blackboard, what I cannot create, I do not understand.

This is exactly the kind of programming experience I need to keep watch over Stack Overflow, and I wouldn't trade it for anything.

You may not be building a website that depends on users entering markup, so you might make a different decision than I did. But surely there's something, some core business competency, so important that you feel compelled to build it yourself, even if it means making your own mistakes.

Programming is hard. But that doesn't mean you should always go shopping for third party libraries instead of writing code. If it's a core business function, write that code yourself, no matter what. If other programmers don't understand why it's so critically important that you sit down and write that bit of code -- well, that's their problem.

They're probably too busy shopping to understand.

Aka: A developers view of the Windows 7 Engineering process

This post is by Larry Osterman.  Larry is one of the most ?experienced? developers on the Windows team and has been at Microsoft since the mid 1980?s.  There are only three other folks who have worked at Microsoft longer on the entire Windows team!  Personally, I remember knowing about Larry when I started at Microsoft back in 1989?I remember he worked on ?multimedia? (back when we used to host the Microsoft CD-ROM Conference) and he was one of those people that stood up and received a ?5 Year? award from Bill Gates at the first company meeting I went to?that seemed amazing back then!  For Windows 7, Larry is a developer on the Devices and Media team which is where we work on audio, video, bluetooth, and all sorts of cool features for connecting up devices to Windows. 

Larry wrote this post without any prodding and given his experience on so many Windows releases these thoughts seemed really worthwhile in terms of sharing with folks.  This post goes into ?how? we work as a team, which for anyone part of a software team might prove pretty interesting.  While this is compared and contrasted with Vista, everyone knows that there is no perfect way to do things and this is just a little well-informed perspective.

So thank you Larry!  --Steven

Thanks to Steven and Jon for letting me borrow their soapbox :-).

I wanted to discuss my experiences working on building Windows 7 (as opposed to the other technical stuff that you?ve read on this blog so far), and to contrast that with my experiences building Windows Vista. Please note that these are MY experiences. Others will have had different experiences; hopefully they will also share their stories here.

The experience of building Windows 7 is dramatically different from the experience of building Vista. The rough outlines of the product development process haven?t changed, but organizationally, the Windows 7 process is dramatically better.

For Windows Vista, I was a part of the WAVE (Windows Audio Video Excellence) group. The group was led by a general manager who was ultimately responsible for the deliverables. There was a test lead, a development lead and a program management lead who reported to the general manager. The process of building a feature roughly worked like this: the lead program managers decided (based on criteria which aren?t relevant to the post) which features would be built for Windows and which program managers would be responsible for which feature. The development leads decided which developers on the team would be responsible for the feature. The program manager for the feature wrote a functional specification (which described the feature and how it should work) in conjunction with development. Note that the testers weren?t necessarily involved in this part of the process. The developer(s) responsible for the feature wrote the design specification (which described how the feature was going to be implemented). The testers associated with the feature then wrote a test plan which described how to test the feature. The program manager or the developer also wrote the threat model for the feature.

The developer then went off to code the feature, the PM spent their time making sure that the feature was on track, and when the developer was done, the tester started writing test cases.

Once the feature was coded and checked into the source tree, it moved its way up to the ?winmain? branch. Aside: The Windows source code has been arranged into ?branches? ? the root is ?winmain?, which is the code base that would ultimately become Windows Vista. Each developer works in what are called ?feature branches?, which merge changes into ?aggregation branches?, the aggregation branches move into winmain.

After the feature was coded, the testers tested, the developers fixed bugs and the program managers managed the program :-). As the product moved further along, it got harder and harder to get bug fixes checked into winmain (every bug fix carries with it a chance that the fix will introduce a regression, so the risk associated with each bug fix needs to be measured and the tolerance for risk decreases incrementally). The team responsible for managing this process met in the ?ship room? where they made decisions every single day about which changes went into the product and which ones were left out. There could be a huge amount of acrimony associated with that ? often times there were debates that lasted for hours as the various teams responsible for quality discussed the merits associated with a particular fix.

All-in-all, this wasn?t too different from the way that features have been developed at Microsoft for decades (and is basically consistent with what I was taught back in my software engineering class back in college).

For Windows 7, management decided to alter the engineering structure of the Windows organization, especially in the WEX [Windows Experience] division where I work. Instead of being fairly hierarchical, Steven has 3 direct reports, each representing a particular discipline: Development, Test and Program Management. Under each of the discipline leads, there are 6 development/test/program management managers, one for each of the major groups in WEX. Those 2nd level managers in turn have a half a dozen or so leads, each one with between 5 and 15 direct reports. This reporting structure has been somewhat controversial, but so far IMHO it?s been remarkably successful.

The other major change is the introduction of the concept of a ?triad?. A ?triad? is a collection of representatives from each of the disciplines ? Dev, Test and PM. Essentially all work is now organized by triads. If there?s ever a need for a group to concentrate on a particular area, a triad is spun off to manage that process. That means that all three disciplines provide input into the process. Every level of management is represented by a triad ? there?s a triad at the top of each of the major groups in WEX, each of the second level leads forms a triad, etc. So in my group (Devices and Media) there?s a triad at the top (known as DKCW for the initials of the various managers). Within the sound team (where I work), there?s another triad (known as SNN for the initials of the various leads). There are also triads for security, performance, appcompat, etc.

Similar to Windows Vista, the leads of all three disciplines get together and decide a set of features that go in each release. They then created ?feature crews? to implement each of the features. Typically a feature crew consists of one or two developers, a program manager and one or two testers.

This is where one of the big differences between Vista and Windows 7 occurs: In Windows 7, the feature crew is responsible for the entire feature. The crew together works on the design, the program manager(s) then writes down the functional specification, the developer(s) write the design specification and the tester(s) write the test specification. The feature crew collaborates together on the threat model and other random documents. Unlike Windows Vista where senior management continually gave ?input? to the feature crew, for Windows 7, management has pretty much kept their hands off of the development process. When the feature crew decided that it was ready to start coding (and had signed off on the 3 main documents), the feature crew met with the second level triad (in my case with DKCW) to sanity check the feature ? this part of the process is critical because the second level triad gets an opportunity to provide detailed feedback to the feature crew about the viability of their plans.

And then the crew finally gets to start coding. Sort-of. There are still additional reviews that need to be done before the crew can be considered ?ready?. For instance, the feature?s threat model needs to be reviewed by one of the members of the security triad. There are other parts of the document that need to be reviewed by other triads as well.

A feature is not permitted to be checked into the winmain branch until it is complete. And I do mean complete: the feature has to be capable of being shipped before it hits winmain ? the UI has to be finished, the feature has to be fully functional, etc. In addition, when a feature team takes a dependency on another Windows 7 feature, the feature teams for the two features MUST sign a service level agreement to ensure that each team knows about the inter-dependencies. This SLA is especially critical because it ensures that teams know about their dependants ? that way when they change the design or have to cut parts of the feature, the dependent teams aren?t surprised (they may be disappointed but they?re not surprised). It also helps to ensure tighter integration between the components ? because one team knows the other team, they can ensure that both teams are more closely in alignment.

Back in the Vista day, it was not uncommon for feature development to be spread over multiple milestones ? stuff was checked into the tree that really didn?t work completely. During Win7, the feature crews were forced to produce coherent features that were functionally complete ? we were told to operate under the assumption that each milestone was the last milestone in the product and not schedule work to be done later on. That meant that teams had to focus on ensuring that their features could actually be implemented within the milestone as opposed to pushing them out.

For the nuts and bolts, The Windows 7 development process is scheduled over several 3-month long milestones. Each milestone allowed for 6 weeks of development and 6 weeks of integration ? essentially time to fine-tune the feature and ensure that most of the interoperability problems were shaken out.

Ok, that?s enough background (it?s bad when over half a post on Windows 7 is actually about Windows Vista, but a baseline needed to be established). As I said at the beginning, this post is intended to describe my experiences as a developer on Windows 7. During Windows 7, I worked on three separate feature crews. The first crew delivered two features, the second crew delivered about 8 different features all relatively minor and the third crew delivered three major features and a couple of minor features. I also worked as the development part of the WEX Devices and Media security team (which is where my series of post on Threat Modeling came from ? I wrote them while I was working with the members of D&M on threat modeling). And I worked as the development part of an end-to-end scenario triad that was charged with ensuring that scenarios that the Sound team defined at the start of the Windows 7 planning process were actually delivered in a coherent and discoverable way.

In addition, because the test team was brought into the planning process very early on, the test team provided valuable input and we were able to ensure that we built features that were not only code complete but also test complete by the end of the milestone (something that didn?t always happen in Vista). And it ensured that the features we built were actually testable (it sounds stupid I know, but you?d be surprised at how hard it can be to test some features). As a concrete example, we realized during the planning process that some aspect of one of the features we were working on in M2 couldn?t be completed during the milestone. So before the milestone was completed, we ripped the feature out (to be more accurate, we changed the system so that the new code was no longer being built as a part of the product). During the next milestone, after the test team had finished writing their tests, we re-enabled the feature. But we remained true to the design philosophy ? at the end of the milestone everything that was checked into the ?main? branch was complete ? it was code AND test complete, so that even if we had to ship Windows 7 without M3 there was no test work that was not complete. This is a massive change from Vista ? in Vista, since the code was complete we?d have simply checked in the code and let the test team deal with the fallout. By integrating the test teams into the planning process at the beginning we were able to ensure that we never put the test organization into that bind. This in turn helped to ensure that the development process never spiraled out of control. Please note that features can and do stretch across multiple milestones. In fact one of the features on the Sound team is scheduled to be delivered across three milestones ? the feature crews involved in that feature carefully scheduled the work to ensure that they would have something worth delivering whenever Windows 7 development was complete.

Each of the feature crews I?ve worked on so far has had dramatically different focuses ? some of the features I worked on were focused on core audio infrastructure, some were focused almost entirely on UX (user experience) changes, and some features involved much higher level components. Because each of the milestones was separate, I was able to work on a series of dramatically different pieces of the system, something I?ve really never had a chance to do before.

In Windows 7, senior management has been extremely supportive of the various development teams that have had to make the hard decisions to scale back features that were not going to be able to make the quality bar associated with a Windows release ? and there absolutely are major features that have gone all the way through planning only to discover that there was too much work associated with the feature to complete it in the time available. In Vista it would have been much harder to convince senior management to abandon features. In Win7 senior management has stood behind the feature teams when they?ve had to make the tough decisions. One of the messages that management has consistently driven home to the teams is ?cutting is shipping?, and they?re right. If a feature isn?t coming together, it?s usually far better to decide NOT to deliver a particular feature then to have that feature jeopardize the ability to ship the whole system. In a typical Windows release there are thousands of features and it would be a real shame if one or two of those features ended up delaying the entire system because they really weren?t ready.

The process of building 7 has also been dramatically more transparent ? even sitting at the bottom of the stack, I feel that I?ve got a good idea about how decisions are being made. And that increased transparency in turn means that as an individual contributor I?m able to make better decisions about scheduling. This transparency is actually a direct fallout of management?s decision to let the various feature teams make their own decisions ? by letting the feature teams deeper inside the planning process, the teams naturally make better decisions.

Of course that transparency works both ways. Not only were teams allowed to see more about what was happening in the planning process, but because management introduced standardized reporting mechanisms across the product, the leads at every level of the hierarchy were able to track progress against plan at a level that we?ve never had before. From an individual developer?s standpoint, the overhead wasn?t too onerous ? basically once a week, you were asked to update your progress against plan on each of your work items. That status was then rolled up into a series of spreadsheets and web pages that allowed each manager to track all the teams? progress against plan. This allowed management to easily and quickly identify which teams were having issues and take appropriate action to ensure that the schedules were met (either by simplifying designs, assigning more developers, or whatever).

In general, it?s been a total blast building 7. We?ve built some truly awesome features into the operating system and we?ve managed to keep the system remarkably stable during that entire process.

--Larry Osterman

One of the points of feedback has been about disabling services and optionally installing components?we?ve talked about our goals in this area in previous posts.  A key driver around wanting this type of control (but not the only driver) is a perception around performance and resource consumption of various platform components.  A goal of Windows is to provide a reliable and consistent platform for developers?one where they can count on system services as being available, as well as a set of OS features that all customers have the potential to benefit from.  At the same time we must do so in a way that is efficient in system resource usage?efficient enough so the benefit outweighs the cost.  We recognize that some percentage of customers believe solving this equation can only be done manually?much like some believe that the best car performance can only come from manual transmission.  For this post we?re going to look into the desktop search functionality from the perspective of the work we?re doing as both a broadly available platform component and to provide the rich end-user functionality, and also look at the engineering tradeoffs involved and techniques we use to build a great solution for everyone.  Chris McConnell, a principal SDE on the Find and Organize team, contributed this post.  --Steven

Are you one of those folks who believes that search indexing is the cause of your drive light flashing like mad? Do you believe this is the reason you?re getting skooled when playing first person shooters with friends? If so, this blog post is for you! The Find and Organize team owns the ?Windows Search? service, which we simply refer to as the ?indexer?. A refrain that we hear from some Vista power-users is they want to disable the indexer because they believe it is eating up precious system resources on their PC, offering little in return. Per our telemetry data, at most about 1.5% of Vista users disable the indexing service, and we believe that this perception is one motivator for doing so.

The goal of this blog post is to clarify the role of the indexer and highlight some of the work that has been done to make sure the indexer uses system resources responsibly. Let?s start by talking about the function of the indexing service ? what is it for? why should you leave it running?

Why Index?

Today?s PCs are filled with many rich types of files, such as documents, photos, music, videos, and so on. The number of files people have on their PC is growing at a rapid pace, making it harder and harder for them to find what they?re looking for, no matter how organized their files may (or may not) be. Increasingly, these files contain a good deal of structure, with metadata properties which describe their contents. A typical music file contains properties which describe the artist, album name, year of release, genre, duration of the song, and others which can be very useful when searching for music.

Although search indexing technologies date back to the early days of Windows, With Windows Vista Microsoft introduced a consumer operating system that brought this functionality to mainstream users more prominently. Prior to Vista, searching was pretty rudimentary ? often a brute force crawl through the files on your machine, looking only at simple file properties such as file name, date modified, and size, or an application specific index of application specific data. Within Windows, a more comprehensive search option allowed you to also examine the contents of the files, but this wasn?t widely used. It was fairly basic functionality ? it treated all files just the same, without the tapping in to the rich metadata properties available in the files.

In Windows Vista, the indexing service is on by default and includes expanded support in terms of the number of file formats and properties which are indexed. The indexer watches specific folders on your PC and catalogues their contents to facilitate fast searching of those files. When Windows indexes your music files, it also knows how to extract the music-specific properties which you?re most likely to search for. This enables support for more powerful searches and richer views over your files which wasn?t possible before. But this indexing doesn?t come free, and this is where engineering gets interesting. There?s a non-zero cost (in terms of system resources) that has to be paid to enable this functionality, and there are trade-offs involved in when and how you pay that price. There is nothing unique to indexing?all features have this cost-benefit tradeoff. 

Trade-Offs

Many search solutions follow(ed) the traditional ?grep? model which means every search will read all of the files you wanted to search. In this case, you paid with your time as you waited for the search to execute. The more files you searched, the longer you waited each time you searched. If you wanted to perform the same search again, you would ?pay? again. And the value you were getting in return wasn?t very good since the search functionality wasn?t particularly powerful. With Windows Vista , the indexer tries to read all of your files before you search so that when you search, it?s generally quicker and more responsive. This requires the indexer to scan all of your files just once initially, and not each and every time you perform a search. If the file were to change, the indexer would receive a notification (a ?push? event) so that it could read that file again. When the indexer reads a file, it extracts the pertinent information about the file to enable more powerful searches and views. The challenge is to do this quickly enough so that the index is always up to date and ready for you to search, but also doing so in such a way that it doesn?t impact the performance of your system in a negative way. This is always a balancing act requiring trade-offs, and there are a number of things the indexer does to maintain its standing as a good Windows citizen while working to make sure that the index is always up-to-date.

A Model Citizen

A lot of work has gone into making the indexer be a model Windows citizen. We?ve written an extensive whitepaper on the issue, but it?s worth covering some of the highlights here. First and foremost, the indexer only monitors certain folders, which limits the amount of work it needs to do to just those files that you?re most likely to search. The indexer also ?backs off? when you are actively using your PC. It indexes files more slowly, or stops entirely depending on the level of activity on the PC. When the indexer is reading files it uses low priority I/O and CPU and immediately releases the file if another application needs access.

It?s critical that we get all of these issues right for the indexer, because it?s not only important for the features that our team builds (like Windows Search), but it?s important to the Windows platform as a whole. There are a host of applications which require the ability to search file contents on the PC. Imagine if each one of those applications built their own version of the indexer! Even if all of these applications did a great job, there will be a lot of unnecessary and redundant activity happening on your PC. Every time you saved one of your documents there will be a flurry of activity as these different indexers rushed to read the new version. To combat that, the indexer is designed to do this work for any application which might choose to use it and provide an open platform and API with flexibility and extensibility for developers. The API designed to be flexible enough to meet needs across the Windows ecosystem. Out of the box, the indexer has knowledge of about 200 common file types, cataloging nearly 400 different properties by default. And there is support for applications to add new file types and properties at any time. Applications can also add support for indexing of data types that aren?t file-based at all, like your e-mail. Just a few of the applications that are leveraging the indexer today are Microsoft Office Outlook and OneNote, Lotus Notes, Windows Live Photo Gallery, Internet Explorer 8, and Google Desktop Search. As with all extensible systems, developers often find creative uses for components for the system services. One example of this is the way the Tablet PC components leverage the index contents to improve handwriting accuracy.

Constantly Improving

We?re constantly working to improve the indexer?s performance and reliability. Version 3 shipped in Windows Vista.  Major improvements in this version included:

• The indexer runs as a system service vs. as a per user process.  This minimizes impact on multi-user scenarios e.g. only one catalog per system results in reduction in catalog size and prevents re-indexing of the same content over and over.  Additional benefit is gained from the robust nature of services.
• The indexer employs low priority I/O to minimize impact of indexing on responsiveness of PC.  Before Windows Vista, all I/O was treated equally.

We?ve already released Windows Search version 4 as an enhancement to either Windows XP or Vista which goes even further in terms of performance and stability improvements, such as:

• Significant improvements across the board for queries which involve sorting, filtering or grouping. Example improvements on Vista include:
  1. Getting all results while sorting or grouping has been improved. Typical query improvements  are up to 38% faster.
  2. CPU time has been reduced by 80%
  3. Memory usage has been reduced by 20%
• Load on Exchange servers is reduced over 95% when Outlook is running in online mode.  With previous versions of Windows Search, large numbers of Outlook clients running in online mode could easily overwhelm the Exchange server.
• Reliability improvements including:
  1. We made a number of fixes to address user-reported situations that previously caused indexing to stop working.
  2. We improved the indexer?s ability to both prevent and recover from index corruptions.  Now, when catalog corruption is detected it is always rebuilt automatically ? previously this only happened in certain cases.
  3. We added new logging and events to help track down and fix reliability issues.

And we?ve done even more to improve performance and reliability for the indexer in Windows 7 which you?ll soon see at the PDC. If you still believe that the indexer is giving you trouble, we?ve got a few things for you to try:

• Download and install Windows Search 4 (on Vista or XP).
• Download and install the Indexer Gadget from the Windows Live Gadget Gallery (Vista only). This gadget was written by one of our team members, and gives you a quick way to view the number of items indexed. It also allows you to pause indexing, or to make it run full-speed (without backing off).
• If you?re one of those people who like to get under the hood of the car and poke around the engine, you can use the Windows Task manager and/or Resource Monitor to monitor the following processes: SearchIndexer, SearchFilterHost, SearchProtocolHost.

If you feel as though your system is slow, and you suspect the indexer is the culprit, watch the gadget as you work with your PC. Is the number of indexed items changing significantly when you?re experiencing problems? If you pause the indexer, does your system recover? We?re always looking to make our search experience better, so if you are still running into issues, we want to hear about them. Send your feedback to idx-help@microsoft.com.

Chris McConnell

Find and Organize

We promised that this blog would provide a view of Engineering Windows 7 and that means that we would cover the full range of topics?from performance to user interface, technical and non-technical topics, and of course easy topics and controversial topics.  This post is about User Account Control.  Our author is Ben Fathi, vice president for core OS development.  UAC is a feature that crosses many aspects of the Windows architecture?security, accounts, user interface, design, and so on?we had several other members of the team contribute to the post. 

We continue to value the discussion that the posts seem to inspire?we are betting (not literally of course) that this post will bring out comments from even the most reserved of our readers.  Let?s keep the comments constructive and on-topic for this one.

FWIW, the blogs.msdn.com server employs some throttles on comments that aim to reduce spam.  We don?t control this and have all the ?unmoderated? options checked.  I can?t publish the spam protection rules since that sort of defeats the purpose (and I don?t know them).  However, I apologize if your comment doesn?t make it through.  --Steven

User Account Control (UAC) is, arguably, one of the most controversial features in Windows Vista. Why did Microsoft add all those popups to Windows? Does it actually improve security? Doesn?t everyone just click ?continue?? Has anyone in Redmond heard the feedback on users and reviewers? Has anyone seen a tv commercial about this feature? 

In the course of working on Windows 7 we have taken a hard look at UAC ? examining customer feedback, volumes of data, the software ecosystem, and Windows itself. Let?s start by looking at why UAC came to be and our approach in Vista.

The Why of UAC

Technical details aside, UAC is really about informing you before any ?system-level? change is made to your computer, thus enabling you to be in control of your system. An ?unwanted change? can be malicious, such as a virus turning off the firewall or a rootkit stealthily taking over the machine. However an ?unwanted change? can also be actions from people who have limited privileges, such as a child trying to bypass Parental Controls on the family computer or an employee installing prohibited software on a work computer. Windows NT has always supported multiple user account types ? one of which is the ?standard user,? which does not have the administrative privileges necessary to make changes like these. Enterprises can (and commonly do) supply most employees with a standard user account while providing a few IT pros administrative privileges. A standard user can?t make system level changes, even accidentally, by going to a malicious website or installing the wrong program. Controlling the changes most people can make to the computer reduces help desk calls and the overall Total Cost of Ownership (TCO) to the company. At home, a parent can create a standard user account for the children and use Parental Controls to protect them.

However, outside the enterprise and the Parental Controls case, most machines (75%) have a single account with full admin privileges. This is partly due to the first user account defaulting to administrator, since an administrator on the machine is required, and partly due to the fact that people want and expect to be in control of their computer. Since most users have an Administrator account, this has historically created an environment where most applications, as well as some Windows components, always assumed they could make system-level changes to the system. Software written this way would not work for standard users, such as the enterprise user and parental control cases mentioned above. Additionally, giving every application full access to the computer left the door open for damaging changes to the system, either intentionally (by malware) or unintentionally (by poorly written software.)

Figure 1. Percentage of machines (server excluded) with one or more user accounts from January 2008 to June 2008.

User Account Control was implemented in Vista to address two key issues: one, incompatibility of software across user types and two, the lack of user knowledge of system-level changes. We expanded the account types by adding the Protected Admin (PA), which became the default type for the first account on the system. When a PA user logs into the system, she is given two security tokens ? one identical to the Standard User token that is sufficient for most basic privileges and a second with full Administrator privileges. Standard users receive only the basic token, but can bring in an Administrator token from another account if needed.

When the system detects that the user wants to perform an operation which requires administrative privileges, the display is switched to ?secure desktop? mode, and the user is presented with a prompt asking for approval. The reason the display is transitioned to ?secure desktop? is to avoid malicious software attacks that attempt to get you to click yes to the UAC prompt by mimicking the UAC interface (spoofing the UI.) They are not able to do this when the desktop is in its ?secure? state. Protected Admin users are thus informed of any system changes, and only need to click yes to approve the action. A standard user sees a similar dialog, but one that enables her to enter Administrative credentials (via password, smart card PIN, fingerprint, etc) from another account to bring in the Administrator privileges needed to complete the action. In the case of a home system utilizing Parental Controls, the parent would enter his or her login name and password to install the software, thus enabling the parent to be in control of software added to the system or changes made to the system. In the enterprise case, the IT administrator can control the prompts through group policy such that the standard user just gets a message informing her that she cannot change system state.

What we have learned so far

We are always trying to improve Windows, especially in the areas that affect our customers the most. This section will look at the data around the ecosystem, Windows, and end-users?recognizing that the data itself does not tell the story of annoyance or frustration that many reading this post might feel. 

UAC has had a significant impact on the software ecosystem, Vista users, and Windows itself. As mentioned in previous posts, there are ways for our customers to voluntarily and anonymously send us data on how they use our features (Customer Experience Improvement Program, Windows Feedback Panel, user surveys, user in field testing, blog posts, and in house usability testing). The data and feedback we collect help inform and prioritize the decisions we make about our feature designs. From this data, we?ve learned a lot about UAC?s impact.

Impact on the software ecosystem

UAC has resulted in a radical reduction in the number of applications that unnecessarily require admin privileges, which is something we think improves the overall quality of software and reduces the risks inherent in software on a machine which requires full administrative access to the system.

In the first several months after Vista was available for use, people were experiencing a UAC prompt in 50% of their ?sessions? - a session is everything that happens from logon to logoff or within 24 hours. Furthermore, there were 775,312 unique applications (note: this shows the volume of unique software that Windows supports!) producing prompts (note that installers and the application itself are not counted as the same program.) This seems large, and it is since much of the software ecosystem unnecessarily required admin privileges to run. As the ecosystem has updated their software, far fewer applications are requiring admin privileges. Customer Experience Improvement Program data from August 2008 indicates the number of applications and tasks generating a prompt has declined from 775,312 to 168,149.

Figure 2. Number of unique applications and tasks creating UAC prompts.

This reduction means more programs work well for Standard Users without prompting every time they run or accidentally changing an administrative or system setting. In addition, we also expect that as people use their machines longer they are installing new software or configuring Windows settings less frequently, which results in fewer prompts, or conversely when a machine is new that is when there is unusually high activity with respect to administrative needs. Customer Experience Improvement Program data indicates that the number of sessions with one or more UAC prompts has declined from 50% to 33% of sessions with Vista SP1.

Figure 3. Percentage of sessions with prompts over time.

Impact on Windows

An immediate result of UAC was the increase in engineering quality of Windows. There are now far fewer Windows components with full access to the system. Additionally, all the components that still need to access the full system must ask the user for permission to do so. We know from our data that Windows itself accounts for about 40% of all UAC prompts. This is even more dramatic when you look at the most frequent prompts: Windows components accounted for 17 of the top 50 UAC prompts in Vista and 29 of the top 50 in Vista SP1. Some targeted improvements in Vista SP1 reduced Windows prompts from frequently used components such as the copy engine, but clearly we have more we can (and will) do. The ecosystem also worked hard to reduce their prompts, thus the number of Windows components on the top 50 list increased. Windows has more of an opportunity to make deeper architectural changes in Windows 7, so you can expect fewer prompts from Windows components. Reducing prompts in the software ecosystem and in Windows is a win-win proposition. It enables people to feel confident they have a greater choice of software that does not make potentially destabilizing changes to the system, and it enables people to more readily identify critical prompts, thus providing a more confident sense of control.

One important area of feedback we?ve heard a lot about is the number of prompts encountered during a download from Internet Explorer. This is a specific example of a more common situation - where an application?s security dialogs overlap with User Account Control. Since XP Service Pack 2, IE has used a security dialog to warn users before running programs from the internet. In Vista, this often results in a double prompt ? IE?s security dialog, followed immediately by a UAC dialog. This is an area that should be properly addressed.

Figure 4. Number of Microsoft prompters in the top 50 over time.

Impact on Customers

One extra click to do normal things like open the device manager, install software, or turn off your firewall is sometimes confusing and frustrating for our users. Here is a representative sample of the feedback we?ve received from the Windows Feedback Panel:

• ?I do not like to be continuously asked if I want to do what I just told the computer to do.?
• ?I feel like I am asked by Vista to approve every little thing that I do on my PC and I find it very aggravating.?
• ?The constant asking for input to make any changes is annoying. But it is good that it makes kids ask me for password for stuff they are trying to change.?
• ?Please work on simplifying the User Account control.....highly perplexing and bothersome at times?

We understand adding an extra click can be annoying, especially for users who are highly knowledgeable about what is happening with their system (or for people just trying to get work done). However, for most users, the potential benefit is that UAC forces malware or poorly written software to show itself and get your approval before it can potentially harm the system.

Does this make the system more secure? If every user of Windows were an expert that understands the cause/effect of all operations, the UAC prompt would make perfect sense and nothing malicious would slip through. The reality is that some people don?t read the prompts, and thus gain no benefit from them (and are just annoyed). In Vista, some power users have chosen to disable UAC ? a setting that is admittedly hard to find. We don?t recommend you do this, but we understand you find value in the ability to turn UAC off. For the rest of you who try to figure out what is going on by reading the UAC prompt , there is the potential for a definite security benefit if you take the time to analyze each prompt and decide if it?s something you want to happen. However, we haven?t made things easy on you - the dialogs in Vista aren?t easy to decipher and are often not memorable. In one lab study we conducted, only 13% of participants could provide specific details about why they were seeing a UAC dialog in Vista.  Some didn?t remember they had seen a dialog at all when asked about it. Additionally, we are seeing consumer administrators approving 89% of prompts in Vista and 91% in SP1. We are obviously concerned users are responding out of habit due to the large number of prompts rather than focusing on the critical prompts and making confident decisions. Many would say this is entirely predictable.

Figure 5. Percentage of prompts over time per prompt type.

Figure 6. Percentage of UAC prompts allowed over time.

Looking ahead?

Now that we have the data and feedback, we can look ahead at how UAC will evolve?we continue to feel the goal we have for UAC is a good one and so it is our job to find a solution that does not abandon this goal. UAC was created with the intention of putting you in control of your system, reducing cost of ownership over time, and improving the software ecosystem. What we?ve learned is that we only got part of the way there in Vista and some folks think we accomplished the opposite.

Based on what we?ve learned from our data and feedback we need to address several key issues in Windows 7:

• Reduce unnecessary or duplicated prompts in Windows and the ecosystem, such that critical prompts can be more easily identified.
• Enable our customers to be more confident that they are in control of their systems.
• Make prompts informative such that people can make more confident choices.
• Provide better and more obvious control over the mechanism.

The benefits UAC has provided to the ecosystem and Windows are clear; we need to continue that work. By successfully enabling standard users UAC has achieved its goal of giving IT administrators and parents greater control to lock down their systems for certain users. As shown in our data above, we?ve seen the number of external applications and Windows components that unnecessarily require Admin privileges dramatically drop. This also has the direct benefit of reducing the total amount of prompts users see, a common complaint we hear frequently. Moving forward we will look at the scenarios we think are most important for our users so we can ensure none of these scenarios include prompts that can be avoided. Additionally, we will look at ?top prompters? and continue to engage with third-party software vendors and internal Microsoft teams to further reduce unnecessary prompts.

More importantly, as we evolve UAC for Windows 7 we will address the customer feedback and satisfaction issues with the prompts themselves. We?ve heard loud and clear that you are frustrated. You find the prompts too frequent, annoying, and confusing. We still want to provide you control over what changes can happen to your system, but we want to provide you a better overall experience. We believe this can be achieved by focusing on two key principles. 1) Broaden the control you have over the UAC notifications. We will continue to give you control over the changes made to your system, but in Windows 7, we will also provide options such that when you use the system as an administrator you can determine the range of notifications that you receive. 2) Provide additional and more relevant information in the user interface. We will improve the dialog UI so that you can better understand and make more informed choices. We?ve already run new design concepts based on this principle through our in-house usability testing and we?ve seen very positive results. 83% of participants could provide specific details about why they were seeing the dialog. Participants preferred the new concepts because they are ?simple?, ?highlight verified publishers,? ?provide the file origin,? and ?ask a meaningful question.? 

In summary, yes, we?ve heard the responses to the UAC feature ? both positive and negative. We plan to continue to build on the benefits UAC provides as an agent for standard user, making systems more secure. In doing so, we will also address the overwhelming feedback that the user experience must improve.

Ben Fathi

It's been well over a year since I joined Telligent as a Remote employee.  I wasn't sure I'd last six months working outside of the main office.  I'm sure these aren't the only tips, but they are the ones that work for me. Maybe some of the other remote peeps at Telligent can offer their 2 cents after reading this.

1. Get face to face

There is nothing like actually meeting the people you work for and with in person on a regular basis.  Before I started at Telligent I made sure I had met several of my co-workers in person during the interview process.  Shortly after was a well timed trip that took us all to Dallas for some face to face meetings.  This time isn't always the most efficiently spent for us remoters, but it's highly valuable social capitol. Simply energizing.

2. Get Visual

If you can't meet in person you can use a number of applications for 1-1 & many to many video chats.  Joe would tell you that it's landlines FTW, but our teams have spoken. Despite the choppy audio, the glitching, CPU usage, and comcastic outages nothing beats video for knowing when your co-workers are rolling their eyes at what you are saying.  So far tokbox & Oovoo have been the most used by our teams.

3. Find your water cooler

It doesn't matter if it's twitter, facebook, or IRC... it's important to have a virtual water cooler with your team.  You need a place to talk about things that aren't precisely what you are working on with your team.

4. Get out of the house and be "that guy"

You need to get out of the house when you start to feel the walls close in around you and productivity drop.  Some of my most productive afternoons have been at the local coffee shop with Wifi, music, and good headphones.  It's extremely energizing just to be around people.

5. Shower and get dressed slacker!

Based on our daily video calls I'm not sure if all of my co-workers agree with this one, but the couple of days I've broken this rule it's cost me in productivity. I just don't feel ready to work unless I'm showered and dressed well enough to appear in public.   You are already saving yourself the 15-30 minute commute you can afford a 10 minute shower.

6. Work a regular schedule

This is another one that may just be me, but just because you work remote doesn't mean you should take advantage of the fact no one will notice you golfing, shopping, or visiting your out of state girlfriend in the middle of the day.  I never realized how important my online status was until last year.

7. Take breaks

Just because you don't take off golfing doesn't mean you shouldn't take breaks throughout the day.  I've found myself, too often, speeding through lunch at my desk while doing e-mail only to realize I hadn't moved much in hours.  That's not an effective break.  Use this time at the virtual water cooler, take 5 minutes to clear the dishes around your desk up, or go outside and get some fresh air.

Update: This was published as a draft before I wrote the last few so enjoy. No sense putting the cat back in the bag... that's painful.

Update 2: Scott posted a list that included some that I hadn?t written up yet here: http://simpable.com/life/working-remotely/ 

To 2nd two of his and add more?

8. Work in a remote culture

If the rest of your team sits in a cube with one another and doesn?t leverage shared communication protocols you?ll probably find yourself on the outside.  Like Scott said? drill them about their culture before you sign up.

9. ALL COMMUNICATION IS MAGNIFIED

Since you don?t see each other every minute you need to realize that every time you do talk to each other the messages you send are amplified to a degree. E-mails may be read more carefully and hints of sarcasm that go over well with people you see in person don?t travel through the series of tubes well. 

10. E-mail etiquette? know when to drop out of mail

Related to 9 standard e-mail etiquette rules apply, but my addition is that I?ve seen too many threads carry on when it would just be faster to grab everyone and hop on a sharedview, call, or chat.  Maybe something to apply is if there are more than 2 replies from 2 unique people? it?s time to drop out of e-mail before more people get sucked into the vortex.

11. Evolve your thinking and your Intranet

I know I?ve personally felt a lot more connected to remote and non-remote employees since we, as a company, started using our own Evolution product.  That?s my biased sales pitch, but the idea is the same no matter what software you use? get people using the social media tools on the intranet that they use outside of work to stay connected.  Get people blogging, creating groups, sharing ideas, posting status messages, etc inside the firewall.

Bonus: Forward thinking

I believe that the tools that enable truly collaborative online working experiences are in their infancy.  Things have evolved so quickly in the last 5 years that the innovations of the next 5 years are going to reshape how people view the need to be sitting next to each other.  They are going to continue to enable you to hire the best people for the job regardless of geography.  It?s going to make us all more efficient.  I think we?re only 10% of the way there today and there is significant room to grow & improve.

Posted to Social

  At times I have to use a low bandwidth internet connection. No matter what my speed,
  though, I'm annoyed when I can't interact with a web site (say, scrolling down or
  following a link) because my browser is busy rendering some complicated chrome I don't
  care about, like a tree view navigation aid. Well, to be honest, I occasionally care
  about that chrome, just not very often.

Try these two links and see which loads faster for you:

http://msdn.microsoft.com/en-us/library/zkch586s.aspx

http://msdn.microsoft.com/en-us/library/zkch586s(loband).aspx

Even on my highspeed setup, I feel a HUGE difference between the two versions of the page. My one complaint about the low bandwidth view is that you can't see the title of the page you're on in the body itself, where it's truncated, though it appears in full in the title bar. Clicking persist low bandwith view puts you in this mode until you get yourself out of it. (The link changes to read switch off low bandwidth view.) This has the advantage that your searches and whatnot will come up faster from now on. Darn right I'm persisting low bandwidth view. I can turn it off if I want more navigation help than the breadcrumbs give me. Here's a glimpse at another page:

What are you missing when you use this view, besides the tree view? A chance to rate the page and add your own content, the collapsing zones (that I never collapse), the language filter ... everything except what you came for - the article or the explanation of the function/object/keyword you wanted to use. If you want the chrome, just turn off the low bandwidth view.

Kate

We?ve booted the machine, displayed stuff on the screen, launched programs, so next up we?re going to look at a pretty complex topic that sort of gets to the core role of the graphical user interface?managing windows.  Dave Matthews is program manager on the core user experience team who will provide some of the data and insights that are going into engineering Windows 7.  --Steven

The namesake of the Windows product line is the simple ?window? ? the UI concept that keeps related pieces information and controls organized on screen.  We?ll use this post to share some of the background thinking and ?pm philosophy? behind planning an update to this well established UI feature.

The basic idea of using windows to organize UI isn?t new ? it dates back (so I hear) to the first experiments with graphical user interfaces at Stanford over 40 years ago.  It?s still used after all this time because it?s a useful way to present content, and people like having control over how their screen space is used.  The ?moveable windows? feature isn?t absolutely needed in an operating system ? most cell phones and media center type devices just show one page of UI at a time ? but it?s useful when multi-tasking or working with more than one app at a time.  Windows 2.0 was the first Windows release that allowed moveable overlapping windows (in Window 1.0 they were only able to be tiled, not overlapping.  This ?tiled v. overlapping? debate had famous proponents on each side?on one side was Bill Gates and on the other side was Charles Simonyi).  In addition, Windows also has the unique notion of "the multiple document interface? or MDI, which allows one frame window to itself organized multiple windows within it.  This is somewhat of a precursor to the tabbed interfaces prevalent in web browsers. 

As a side note, one of the earlier debates that accompanied the ?tiled v. overlapping? conversations in the early Windows project was over having one menu bar at the top of the screen or a copy of the menu bar for each window (or document or application).  Early on this was a big debate because there was such limited screen resolution (VGA, 640x480) that the redundancy of the menu bar was a real-estate problem.  In today?s large scale monitors this redundancy is more of an asset as getting to the UI elements with a mouse or just visually identifying elements requires much less movement.  Go figure!

From Windows 2.0 to Vista.

An area I?ve been focusing on is in the ?window management? part of the system ? specifically the features involved in moving and arranging windows on screen (these are different than the window switching controls like the taskbar and alt-tab, but closely related).  In general, people expect windows to be moveable, resizable, maximizable, minimizable, closeable; and expect them to be freely arranged and overlapping, with the currently used window sitting on top.  These transformations and the supporting tools (caption buttons, resize bars, etc) make up the basic capabilities that let people arrange and organize their workspace to their liking. 

In order to improve on a feature area like this we look closely at the current system - what have we got, and what works?  This means looking at the way it?s being used in the marketplace by ISVs, and the way it?s used and understood by customers.

Caption buttons give a simple way to minimize, maximize, and close.  Resizable windows can be adjusted from any of their 4 edges.

Data on Real-World Usage 

As pointed out in the previous Taskbar post, on average people will have up to 6 ? 9 windows open during a session.  But from looking at customer data, we find that most time is spent with only one or two windows actually visible on screen at any given time.  It?s common to switch around between the various open windows, but for the most part only a few are visible at once.

Windows Feedback Panel data

As part of our planning, we looked at how people spend their time and energy in moving and sizing their windows. This lets us understand what?s working well in the current system, and what could be improved.

For example, we know that maximize is a widely used feature because it optimizes the work space for one window, while still being easy to switch to others.  Users respond to that concept and understand it.  Since most of the time users just focus on one window, this ends up being very commonly used.  We know that for many applications people ask for every single pixel (for example spreadsheets where a few pixels gain a whole extra row of column) and thus the beyond maximize features for ?full screen? become common, even for everyday productivity.

An issue we've heard (as recently as the comments on the taskbar post!) with maximize in Vista is that the customized glass color isn?t very visible, because the windows and taskbar become dark when a window is maximized. (In Vista you can customize the glass window color ? and in 29% of sessions a custom color has been set).  The darker look was used to help make it clear that the window is in the special maximized state.  This was important because if you don?t notice that a window is maximized and then try to move it, nothing will happen - and that can be frustrating or confusing.  For Windows 7 we?re looking at a different approach so that the customized color can be shown even when a window is maximized.