The Galactic Patrol : Microsoft

Interested in Indigo?

bwill — Wed, 23 Mar 2005 02:42:00 GMT

I've been posting some comments about Indigo on my other blog - feel free to subscribe if you're interested in Indigo. Here are some of the Indigo entries I've written:

http://galactic-patrol.blogspot.com/2005/02/indigo-is-re-released-into-wild.html

http://galactic-patrol.blogspot.com/2005/02/to-indigo-clr-contract-is-not.html

http://galactic-patrol.blogspot.com/2005/02/serviceoperation-wheres-message.html

http://galactic-patrol.blogspot.com/2005/03/indigo-testing-take-pretty-things-and.html

http://galactic-patrol.blogspot.com/2005/03/got-indigo-questions.html

http://galactic-patrol.blogspot.com/2005/03/whats-right-way-to-dispose-channel.html

Fair warning, I do occasionally blog about non-technical topics.

fetching you a bottle of water does not motivate me

bwill — Thu, 24 Jun 2004 13:29:00 GMT

This is the story of an inspirational speech that, well – wasn’t.

I went to a divisional meeting recently – lots of people, lots of powerpoint. The topics were a bit dry, and the last speaker was clearly trying to drum up some excitement and enthusiasm. He started telling us a story about Lance Armstrong. “People think of him as this amazing solo performer,” he said, “but he relies on his team to make him a success.” He goes on to tell us about the nine other people on the tour-de-france bike team with Lance. They are so motivated. They are so dedicated. He tells us how they let Lance draft behind them. He tells us how they sprint ahead to tire out all the other competitors. He goes into this long sequence about how one of Lance’s teammates, tired as hell, still turned around, went back down the hill, grabbed eight bottles of water, and then sprinted back up the hill to give the water to Lance. I have to tell you, the whole presentation left me flat – if anything, it unmotivated me.

Its possible I was just in a bad mood that day. Its possible that I’m just not a big cycling fan. (Heresy for a Redmond resident, I know.) But really – if you want to motivate me, tell me that I can be Lance Armstrong – not just his waterboy.

How well do you know your Microsoft acronyms?

bwill — Wed, 23 Jun 2004 05:30:00 GMT

I made the following challenge over on Channel 9 – anyone care to take up the gauntlet?

“That takes me back - when I started at Microsoft eight years ago, I worked in the Windows build lab. This was back when we were working on SUR, and IIS 1.0. We used SLM instead of SD, and there were no VBLs. Working in the neck of the software development funnel was quite an experience back then - and I'm sure the challenges of the job have not decreased over the past eight years.

10 points to anyone who can identify all the acronyms I used above. (Ok, only 5 points if you are an MS employee.)”

[UPDATE: Kevin Dente got them all right - I suggest guessing before reading the comments on this entry if you want to play along.]

Pat Helland blogging

bwill — Sat, 13 Mar 2004 04:16:00 GMT

Wow, Pat Helland is blogging – that’s too cool.

Update: for those who don't know of Pat - he is very knowledgeable about distributed architecture issues, and also has a wonderful way of explaining them. If you ever get a chance to hear him talk, I recommend it. Recently, for example, he coined the great acronym HST:

http://www.developingstorm.com/2004_02_01_archive.php#107642035307250461

how to contact me

bwill — Fri, 12 Dec 2003 08:12:00 GMT

I published this info when I started my GotDotNet blog; with the move, now is a good time to re-present the info:

Bruce Williams

I am a test developer for Indigo – current and future Web Services technology at Microsoft.

e-mail: bwill@microsoft.com

IM: domanite@hotmail.com

Be verwy verwy quiet - we're hunting bugs!

bwill — Fri, 26 Sep 2003 09:16:00 GMT

Eric Lippert has a great post describing some of his adventures with security issues in VBScript. I particularly liked this segment:

“Of course, it could be worse. There was a bug in early versions of the CLR (which I believe was fixed before the first beta shipped, fortunately) where you could get an error message something like

Path discovery security exception: You are not allowed to determine the name of directory 'c:\foo\bar'

Super! Thanks for letting me know!”

old (and long) e-mail ramble about agent technology and other trivia

bwill — Fri, 26 Sep 2003 08:59:00 GMT

Peter’s response to my TiVo post for some reason reminded me of a rambling e-mail conversation I had several months ago; for your amusement I repeat it below. Incidentally, mail threads like this are reason #128 why I like working at Microsoft…

From: Ken
Sent: Thursday, July 17, 2003 12:12 PM
To: Barry; Michael; Wade; Richard; Mark; John; Keven; Praveen; Bruce
Subject: How many lines of code can fit on the head of a pin?
Importance: Low

Discussion that arose questioning how many lines of code there are in the world.

We were discussing Feynman and his thoughts on miniaturization, nano-tech, etc….many years ago he put forward a challenge to reduce a page of text to 1/2500^th of it’s original size. At the time he made this challenge, all of the books in the world would be able to be “printed” on a sheet 3 meters on each side (9m^2 area). Note that this was not encoding, but actually forming all letters, pictures, etc. The original challenge was met (to make this a bit more “real”, think of the 30 volume Encyclopedia Britannica…at 1/2500 it would all of the pages would fit on the head of a pin).

So, to us geeks, the natural question arises, how big of an area to print all the code? What if you didn’t print it, but encoded it (I would guess that you’d want at least 3 atoms/bit to make retrieving it a bit easier.) Of course you could use single atoms to represent more than a bit, one carbon atom might represent ‘0’, gold atom for ‘1’, platinum for ‘2’, lead for ‘3’…just right there we’ve reduced the size of a two-dimension printout by a factor of four.

My initial “quick-thought” below.

A co-worker and I were discussing this today:

· How many lines of code (LOC) are there in the world?

· What if you limit it to 'active' code?

· What's the ratio of total lines to active lines?

· Are there more LOCs than lines in books?

I'd guess somewhere in the realm (within a couple orders of magnitude) of 10 Billion LOC (which is based somewhat on how many LOC I think are at Microsoft), with the Total/Active ratio somewhere around [2-3]:1.

Based on an older, but probably still "right ballpark", figure of 30 million books in the world (taken from Feynman's The Pleasure of Finding Things Out) and supposing that an average book has 750 pages with 50 lines each we'd get 1,125,000,000,000 lines (a bit over a trillion lines). As this is several orders of magnitude above my guess, I’d bet that books have the lead.

PS: Why the strange “To:” line? Figured I’d include the folks that worked on the horrid LOC project, some of the stranger thinkers I know, a tried and true researcher (who probably also fits in the previous category), the man whose initials are found in BILLIONS of executables. No “deep-thought” answers required, but if you’d like to chime in let me know if I can include your thoughts on my web page.

From: Mark
Sent: Thursday, July 17, 2003 2:54 PM
To: Ken; Barry; Michael; Wade; Richard; John; Keven; Praveen; Bruce
Subject: RE: How many lines of code can fit on the head of a pin?

Rambles:

I think there are way more than 30M books. Harvard’s library has 11M+. What does LOC (Library of Congress) have in it?

Feynman was merely talking about taking the existing representation (aka print) and shrinking it. Clearly, printing code and then shrinking it will have the same set of issues.

Certainly, we can encode the book in atoms, but thermal, chemical, and quantum issues make reading the data interesting. If reading wasn’t interesting, then I could encode it all in one bit. 0 means not the entire set of code. 1 means the entire set of code. If you valued reading, then the issue of specifying the decoding algorithm should be brought in. With the single bit interpretation above, you could end up with a mighty complex decoding algorithm.

Thermal issues:

Atoms move about unless really close to absolute zero, even in solids. Trying to measure single atoms might be fairly difficult;

Chemical issues:

OK, are we talking one-time encoding or an encoding that can be used for archival? The former is easy, but things like oxidation, photochemistry, etc. will impact just how dense we can make things.

Quantum issues:

Yes, atoms are quantum beasts. Measuring them in a non-destructive fashion might also be difficult.

Backing out of physics, from the standpoint of encoding, you could simply encode the ASCII representation (what do you do about those EBCDIC Cobol and RPG programs?). But code is also notoriously compressible (ala LZW). LZW is nice because it’s dictionary-free; the dictionary is the previously input data. You can do even better with Markov modeling of the code, but you’d have to include the size of the Markov tables as well in the size. The Markov models could be for individual characters or for lexical items. You could also do something along the lines of encoding the parse tree of the source file (suitably annotated with comments). Handling .h files might be dicey.

Enough with rambles…

From: Ken
Sent: Thursday, July 17, 2003 3:59 PM
To: Mark; Barry; Michael; Wade; Richard; John; Keven; Praveen; Bruce
Subject: RE: How many lines of code can fit on the head of a pin?
Importance: Low

11M is the number that Feynman quoted for Lib o’ Congress…I think he gave the speech where quoted 30M in the late 60’s, but the book I’m “reading” (listening to) jumps around from childhood right up to the late 80’s. During the speech he actually describes a method for reading the “small print”…but at the time the technology hadn’t gone far enough to print it yet. With the rise of the Internet/PC/easy publishing, I’d be surprised if the number was not at least around 60M these days (double the number in the 60’s)…while I’d be surprised if it was in the 100M or above, I don’t see even that sort of number as inconceivable.

As we approach the means to really make good on some of Feynman’s “plenty of room at the bottom” dreams (Cornell made a 1-atom wide transistor a bit over a year ago), I find myself looking at things like this more and more. Due to my sordid past, the notion of a coming up with a good (and defensible) estimate for the number of LOC in existence strikes me as a fun exercise. The real meat isn’t there, nor is it, other than as a “perspective exercise”, in figuring out how big (small) of a piece of something you would need to hold it.

Granting that there will be a host of new difficulties when we start getting components that are made at the atomic level, I think that we will live to see the truly tiny become reality. As we creep into nano-tech, the processes and research will (I hope and believe) begin to build on each other. While we may not be part of the world of physics (and chemistry, and bio-chem, and…) that will be building these gadgets straight out of the most far-fetched science fiction, it will be up to us to help define at least how some of this stuff will benefit the “common man”. What changes do we make to the operating system, to Office, etc when a person can have a couple of terabytes of storage with them all the time? How soon before it’s not only feasible but practical to record everything we read (http://SIS is close on this front), hear, say, or see…index it all while we sleep, and “auto-fill” details the next day when we start writing a report?

I used to chuckle when I read old Robert A. Heinlein books and he had a character load terabytes of information onto a small cube.

Thermal, Quantum, Chemical…and the list goes on, but I do think the world has the set of minds as well as the preparation of the giants of the last century to beat these problems (actually, in some ways the thermal might work for us). Anyone want to adopt me so I can head back to college…thinking I’d enjoy a decade or two back in school.

From: Bruce
Sent: Thursday, July 17, 2003 6:55 PM
To: Ken; Mark; Barry; Michael; Wade; Richard; John; Keven; Praveen
Subject: RE: How many lines of code can fit on the head of a pin?

We are moving to a world where there is more information than a single person can process. People will have to become more and more selective in the data they choose to read. (or see, or hear, or taste…) As a computer person, I view this as a problem to be solved, and my first instinct is to hypothesize a solution involving a software agent that can selectively choose and display only those facts and media that fit some criteria we give it.

However, I see this as bringing us to a more devided and insular world. Democrats will have agents that spin things they way they want to see them; Republicans likewise. I’m sure the sci-fi fans will continue to form their own strange sub-culture. Ones entire world view will be shaped by what one chooses to experience, and when there is a surfeit of information that does appeal, folks will be less and less inclined to view that which does not.

In some sense, our choice of agent will decide who we are, and who we become. (At least to the extent that one believes in nurture over nature.) Could one then change oneself by altering the agent programming? In any kind of serious, personality-altering way? What happens if some hacker gets into your agent, or the men in the black helicopters do?

Beware – here there be dragons

From: Richard
Sent: Friday, July 18, 2003 2:36 PM
To: Bruce; Ken; Mark; Barry; Michael; Wade; John; Keven; Praveen
Subject: RE: How many lines of code can fit on the head of a pin?

Everyone reading this thread is the product of a lifetime of agents choosing and biasing what media we consume.

It starts with our parents and families, and churches, friends, Television, the so called “mass-media”, then later teachers in school, employers, and government, etc.

These agents also already have their hackers, which can be though of as agents themselves. These are the same form as the agents that affect us. Though they may be different TV shows, different media, different teachers, and different employers.

Every time you hear of censorship, political correctness, and boycott are examples of agents attempting to restrict the exposure of content.

Every time you hear of praise and awards agents are promoting content.

Other things like reviews and bias reporting can swing either way.

But it is all affecting the perceived worth of consuming the target content and ideas.

Its all a tight feedback system. It would seem that the truest “individuals” would live in the wilderness with no outside influence. But if we met someone like that we’d likely not enjoy their company nor would they enjoy ours. We enjoy being with people more when we can communication and have thoughts and topics to share. This is one of the feedbacks.

We choose our agents when we choose our books, schools, subscriptions, employer, clubs, homepage, and program our Tivo.

No doubt this does affect who we become.

I wonder if agent selection will ever become as sophisticated as allowing me to choose what personal traits I’d like to make stronger.

You turn up your agent’s sensitivity dial and Tivo starts recording “Little House and the Prairie” and “Touched by an Angel”

Ramble on…

From: John
Sent: Friday, July 18, 2003 2:36 PM
To: Bruce; Ken; Mark; Barry; Michael; Wade; Richard; Keven; Praveen
Subject: RE: How many lines of code can fit on the head of a pin?

(This thread is getting pretty far a field.)

As Richard points out knowledge is already being filtered by "agents" (many of which are not user configurable.) So at the end of the day we have to examine the trust relationship between ourselves and those agents.

Some of the things I have noticed:

- The less interested you are in a topic, the more you are willing to trust the agent. The more you are interested (and experienced) in a topic the more scrutiny you will give to the agent.

- Once an agent has seriously disappointed you never trust the agent again.

- The more you are exposed to agents as a class the less you trust them.

Think about really, really good internet trolls: they contain enough fact, wit, and divisiveness to cause chaos amongst the most well ordered communities. What about trolls that build a trust relationship first?

Think about what makes a trust relationship. Generally you have seen some objective demonstration that convinces you, and you are willing to believe the demonstrator on related subjects without objective proof. Perhaps the objective demonstration is abstracted through a certification authority, like a drivers license: you didn't see me take the test, but I can show you my license. Think about all of the points of failure in this trust system. Having or not having a drivers license doesn't prove or disprove ability to drive.

While you could certainly manipulate people through media collection agents, There is still (and always will be) informal agents with a disproportionate amount of trust. If your grandmother told you something you would probably believe her, unless you had objective proof, or special knowledge. Grandma is an informal agent that gets a huge amount of trust, and it is very difficult to erode that trust (unless she drinks or something)

The concept of tweaking your agents for "self-improvement" is interesting (assuming a direct correlation between watching lots of Lifetime TV and being more sympathetic) although you would also have to tweak your informal agents as well. Basically you watch all of the Oprah in the world but until you quit the Hell's Angels I don't think you are going to start crying at movies.

- John

Fault injection tools from Microsoft

bwill — Wed, 24 Sep 2003 18:52:00 GMT

In a response to my recent post on fault injection, Mark asks if I know of any publicly-available fault-injection frameworks. Yes! In fact, much of the fault-injection work done at Microsoft is built on top of work done by Microsoft Research, and you can also take advantage of their work. In particular, look at the Detours tool for injecting code into an existing binary.

Unfortunately, Detours only does native code, not managed code. We do have managed code injection tools internally, but I don’t see them on the research site, so I guess they are ‘top secret’. You are in luck, however; I’ve also heard of a well-known fault-injection tool called Holodeck, that does do managed code. This also has the advantage of providing a nice user interface and support tools – a point-n-click operation. Detours is a bit more low-level, and requires some coding and work on your part. Unfortunately Holodeck does appear to be pretty pricy - $5000 for a single license. Let’s keep looking…

A google search on fault injection finds a bazillion hits – take a look there and see if you can find a tool that meets your needs.

Code Name: "Avalon"

bwill — Tue, 23 Sep 2003 23:51:00 GMT

I noticed this link to Wesner Moise’s comments on Microsoft’s “Avalon” technology, to be debuted at PDC. I’m certainly no Avalon expert, but I’ve been to their internal web site, and saw a demo once. This is killer stuff. Not wanting to be fired, I probably shouldn’t discuss it too much, but I will say that it’s a large project, and it covers a lot of different areas of functionality. Whenever we have something that big, and new – we really, really want to get lots of good feedback, so we can make it useful (or, dare I say it, indispensable) by the time we actually ship it. And, its really, really cool.

So if you have the opportunity, go see the Avalon presentations, and let us know what you think.

(After you go to the Indigo presentations, of course! <grin>)

(Link found at SimpleGeek.)

For a good time, call 1-800-FAULT-INJECTION-TESTING

bwill — Tue, 23 Sep 2003 08:49:00 GMT

We have occasional debates here at Microsoft on the value of ‘white-box’ testing. (For the sake of this discussion, ‘white-box’ testing means testing that takes advantage of internal product knowledge, while ‘black-box’ testing relies solely on the published API and behavior.)

On the one hand, if the person who developed code writes the test for it, or if the tester was intimately involved in the design of the feature, then the test design is often blinded by the dev design. For example, if the development of the feature goes to great lengths to ensure that the threading and locking behavior is correct, then the tester may spend a majority of their test effort there. This is a problem if, for example, there are major flaws in the way the feature interacts with its config files. You don’t want a certain focus in product development dictating a similar focus in test development.

On the other hand, there are some kinds of bugs that can *only* be found with white-box testing. If code has an off-by-one error that only kicks in at the exact buffer size that switches between the fast-path algorithm and the slow-path algorithm, there is every possibility that even well-designed equivalence classes against the published API won’t find the problem. A quick peek at the code, however, can tell you exactly what buffer size to use, if you want to give the product a conniption fit.

However, there is one kind of white-box testing that is pretty much universally seen as useful – fault injection testing. This is where you inject code at compile- or run-time to force faults that would not normally occur. These are great! Once you have a fault-injection test framework set up, a fault scenario that might ordinarily require an IBM mainframe database and a female goat can be duplicated in a few couple minutes, with a few simple lines of code. If you are hard-core about testing error handling in your program, you owe it to yourself to investigate fault-injection schemes. It is similarly good for increasing code-coverage numbers, if you use that metric.

Now, there are a lot of different ways you can do fault injection. Recently I’ve seen some work done injecting faults at the protocol level during SOAP message transmission. It is interesting to send SOAP messages from one place to another, and have a little bitty guy who sits in between and drops, alters, or otherwise interferes with the messages flowing by. (Would that be an example of MaXMLwell’s Demon?) Going further back in the past, I’ve seen a system that systematically generated every possible memory allocation fault while running our test suite.

Now, that last example brings up the ‘dark side’ of fault injection testing. You see, there were a couple problems with that memory allocation testing. Here is how it worked:

1. Pick a single test variation from your test suite, and run it. Keep a count of the number of memory allocations executed.

2. Run the variation again. Fail the first memory allocation, and all subsequent ones.

3. Run the variation again. Fail the second memory allocation, and all subsequent ones.

4. Keep doing this until you’ve gone through the entire set of memory allocations that a successful variation run does.

5. Go to the next test variation.

Now, the most obvious problem is that this test takes *forever* to run. It literally took weeks to run through a simple set of COM tests. (Oops, did I accidentally reveal the product in question?) You really have to look at the bugs you find with this method, and ask yourself “is finding these bugs worth the cost of the testing?” There might be other testing you could be doing that would find better bugs, or find bugs more efficiently. So if you are doing ‘high-volume’ fault injection, you really need to balance the cost of the testing against its value to you.

Another problem, really more of a nit, is that while this method seems comprehensive, there are many cases it doesn’t hit. What if the memory allocations are only failing intermittently? If something fails only on the pattern “allocation failed, allocation succeeded, allocation succeeded again, allocation now fails again”, then the test above won’t find it. I don’t have an answer to this one, except to give the sad truth that you can always think of more things to test, than you could possibly actually write (or run) tests for.

Another, much more significant problem, is this: how do you know if it failed? We took the easy way out, and said “if it AV’s, blue-screens, or otherwise crashes – it failed.” So if it appears to succeed; or if it returns a wrong error code; or if the behavior of the program is just wrong, in a non-crashing way – we would not detect it. Why did we do this? Well, remember our discussion of costs and tradeoffs. I’ll give you a million lines of test code, developed over ten years by 40 different people. Are you gonna track through that and fix it so it reports errors correctly *for every possible memory allocation failure path*? Note that I’m not claiming that level of detailed testing isn’t useful – it just wasn’t feasible in that case, on the scale of the entire test suite. Picking a set of core functionality and writing some exceptionally robust test code specifically for this type of fault injection scenario might be a useful endeavor. We’ll see. <grin>

For those concerned about Microsoft code quality, note that these days we do also have some static analysis tools that will churn through a reasonable subset of possible call graphs in our programs, and report possible problems in error paths. It even files bugs automatically – the Windows folks love that, I’m sure!

Some of my readers may be familiar with Microsoft’s stress-testing efforts, where we often hammer a machine with tests to the point of program failure. While stress testing is useful, don’t be fooled into thinking that it is an adequate replacement for fault-injection testing. The biggest problem with stress testing is the “early exit” problem. If you are crushing a machine to the point that memory allocations are failing, then most programs are just going to die immediately when you run them. You are only going to end up testing the first 10% of the program, which presumably is not the intent. Another issue is that stress test failures tend to be non-deterministic; you don’t necessarily know when (or if) a particular failure will occur, and it can be very difficult to determine the actions that led up to the failure. This makes debugging a stress failure much more, well, stressful; than debugging an equivalent failure in a fault injection test.

Lastly, note that (as with so many of the topics I write about), there is much, much, more to it than I have written. For example, there are many different kinds of faults that you can inject. We talked about memory faults and protocol faults; but there are also file access faults, security faults (a biggie!), system object access faults (events, mutexes, etc), registry faults – you can even feel free to inject faults into your own internal product code – what happens when your lower-level stuff throws an exception to the higher-level stuff?

It is really not that hard to get started with, however; and I highly recommend it.

Test tracing - it is not optional!

bwill — Sun, 21 Sep 2003 02:15:00 GMT

I’d like to talk about one of the first lessons I learned as a tester at Microsoft:

Anticipate failure investigations, and log everything.

Let me tell you a fairly rambling tale of my early days at Microsoft:

We’d just shipped Windows NT 4.0 (and IIS 1.0). I’d recently moved from a contract position in the Windows build lab; to a full-time position (aka FTE, aka ‘blue-badge’) in the COM test team.

In those days, the COM team was just beginning its transition from a consumer, drag-n-drop, linking-and-embedding technology; to a distributed computing, enterprise-application sort of focus. This was all before COM+; DCOM was the new thing. Given that history, it is perhaps not surprising that we had a bunch of old tests covering a variety of those aforementioned consumer-oriented applications of COM. Linking and embedding, COM common dialogs, and more; these were tests that had been lovingly handed down from tester to tester over the years.

You’ll recall I mentioned a transition. Now, those who have been in the industry for a while know what it means when the product changes focus like that. Resources shift. Things happen, like taking these “upper layer” tests from the five experienced testers who owned them, and giving them to a new, green tester fresh from the build lab. Sink or swim, as they say. Let me tell you, taking over maintenance of a large test suite (written by a number of different people, in a number of different styles *ping*) is a great way to learn some valuable lessons about test code design.

For example, there was a test for the OLE common dialogs, used for inserting OLE objects and other operations. This test basically ran a large script (*ping*) that iterated through a bunch of scenarios exercising these dialogs. In total the scripts performed thousands of operations – click that button, move that window, select this other menu option, etc. Now, any time you have one program executing a script like that, you basically have one program running another program. This means it is particularly difficult to figure out, from a debugger, what the dang thing is doing. When you break in, the stack just shows you what the script interpreter is doing, and it requires some investigation of the program variables to figure out where you are in the script being interpreted.

Now, the test had a log file output, but unfortunately when I acquired the test this output was fairly minimal. Let me tell you, debugging a failure in this test was an adventure! It was time-consuming, and technically challenging. (Technically educational, too, I will say.) So I went into the interpreter and did something very simple – I just logged each unique operation as it executed:

LOG TRACE: Menu Select ‘File Open’

The logs got a lot bigger, and the test ran marginally more slowly (those UI tests tended to be dog slow, anyway), but now when something failed, I could look at the log and see the precise script actions that led up to the failure.

So what I learned is that it is really, really important in a test to log *everything*. Log your inputs; log your outputs; log all the program variables that seem even halfway interesting. It will make your life so much easier. It will make the life of the next test maintainer so much better. If it causes a severe performance hit, *then* you can perhaps think about placing some of the trace output under a switch, that you can enable or disable as needed for debugging purposes. Even there, make sure you can turn on the trace output without having to recompile the program – you’ll thank yourself later.

On a side note, in the last couple years I’ve noticed a trend in Microsoft product design to add this kind of detailed tracing to our products. Debug level tracing, in the production code – something you can enable or disable with a program or registry entry. I know that DTC has done this for a while, and I believe it has been standard practice in the mainframe world for decades. Of course, for performance reasons the tracing is typically turned off in normal execution – but it is there, and it doesn’t require a re-compile to enable.

PSS loves this – it really helps them track down and solve customer problems.

Pre-PDC checklist

bwill — Sat, 20 Sep 2003 23:39:00 GMT

I’ve never been to an industry conference (yet; I keep trying to convince my management to send me…), but to my uneducated eye, this pre-flight PDC checklist by Adam Cartwright looks eminently useful…

more Scoble stuff - there are many parts, but only one Microsoft

bwill — Sat, 20 Sep 2003 23:14:00 GMT

Again, while reading this same Scoble post, it got me thinking about my role at Microsoft. When I tell people what I do at Microsoft, I say "I do software testing. If you find a bug in a Microsoft product, it is my fault."

Of course, that is a vast oversimplification. I work on one part of one product, that isn't even released yet. I could easily disclaim responsibility for the particular problems people are having. But that’s not the kind of person I want to be. That’s not the kind of company I want to be part of. And if I don’t take the responsibility, who will?

Scoble talks about "us" at Microsoft

bwill — Sat, 20 Sep 2003 23:09:00 GMT

I was reading this recent post on Scoble’s blog, where he talks about how he refers to “we” and “us” when talking about Microsoft. A friend of mine told me once that they found it unusual that I say "we" and "us" when referring to stuff that Microsoft does. Apparently that isn't the habit where they work. They tell me that its cool that I like my work enough to talk about it that way. I think its cool too.

I'm going to miss the company meeting!

bwill — Sat, 20 Sep 2003 08:24:00 GMT

Damn! I just found out that the Microsoft Company Meeting, a yearly event, is on October 30^th, and I will be out of town! Its hard to describe these meetings; but let me try.

You walk into SafeCo field, Seattle’s new baseball stadium, and look around, admiring the sheer size of the place. The sliding retractable roof, with its shell-like design and bright red struts and wheels is particularly eye-catching. You probably came together with some other folks from your team; there is a good chance you are all wearing the same shirt. On your way in, you pass through some security – check that blue badge, please! And open your bag – no cameras at this event; top-secret demos coming up. Grab a drink – a water or soda – on your way to your seat; you’ll need it. There are some snacks too, although they tend to be a bit on the healthy side for a true junk-food junky like myself.

You make your way to your seat – its assigned seating, and your whole team is sitting together. You chat with your teammates while waiting for the show to start – or perhaps watch interesting historical facts about Microsoft flash by on the enormous video screens that flank the temporary stage plopped on top of the pitcher’s mound like an encroaching amoeba. At some point, the inevitable happens, and those on the upper decks begin to make paper airplanes out of various maps, instructions, and other hand-outs. The airplanes float down, in curves and lines, bouncing against the occasional wall or head. Nobody says it, but the challenge is clear; to construct an airplane so honest and true that it flies long, and flies straight, and manages to actually land on the stage. Oh! That one was close; it hit one of the large video screens, and dropped on top of a smaller (60”?) TV close to the stage.

The PA system crackles, and soon the show will start – the minutes tick by, and the crowd quiets. Then it begins. The first Microsoft executive steps up on stage, and begins to talk. It’s the Chief Operating Officer, and he’s giving us a status update on the plan. Here is how the divisions are doing. Here are the financials. Some slides, and charts. A little bit of inspirational chat – we think we can grow the server business by XX percent over the next three years! We are investing heavily in mobile technologies! A thunderous cheer erupts from the WinCE contingent, and confetti blizzards down onto those fortunate enough to sit below. For the most part, though, the talk is fairly factual and dry.

Then the parade of Vice Presidents begins – Jim Allchin, Jeff Raikes, Paul Maritz, and more. They discuss the challenges and successes of the various parts of the company. Some plans are discussed, although this tends to be a bit vague; perhaps they don’t think they can really keep every nosy reporter out of the stadium, if that reporter had a serious mind to sneak in. They do show demos, though; really, really cool demos. You lean forward in your seat – its one of the highlights of the show. In past years, in the late 90’s, they would bring in comedians or other acts to liven things up; but recently it has been a bit more business-like. Still a show, though. And you really like the demos.

Intermission comes; time to stand in line. Get a snack, go to the bathroom – grab another couple bottles of water. Some silly baseball cheering game is on the video monitor; see which side of the stadium can make their boat go faster. You don’t really care, but it’s a good opportunity to stretch, talk with teammates, and return your wife’s call on the cell phone. More airplanes float down from the upper deck, but somehow they seem sloppier, and none comes close to the stage.

Intermission ends, and to a dramatic fanfare, Bill Gates steps on stage. Deep analysis of technological trends follow. A big picture emerges. Some of the stranger technological bets that Microsoft has made, start to make sense. A vision arises, of computing and the future. You wonder if he writes his own speeches. He finishes, to great applause, and steps down.

Then flashing lights begin, the music cranks up a notch, and Steve Ballmer jaunts on-stage. The man has unnatural levels of energy and enthusiasm. He jumps around the stage, almost dancing or skipping. He roams the seats and takes high-fives. He waves his hands, encouraging and exhorting applause. He also talks directly, and seems to address some of the deep concerns of the employees directly: What kind of company are we? What kind of people are we? What do we want to accomplish? It is inspirational; sometimes deep, sometimes silly – but always passionate, always heart-felt. You want to believe this man, and you want to follow him. It is really, really cool.

When Ballmer leaves, you know you’ve been treated to a good show. Everyone stands up, and begins to file out of the stadium. Many people go directly to the busses, and head back to campus. You, however, go across the street to the convention center. More food, there, and booths set up by many of the teams from inside the company. They are showing off their latest and greatest stuff – more nifty demos, and lots of trinkets to pick up. Pens, pads, software. Lucky you brought a bag with you. In the center, an Xbox tournament is underway, giant video screens blazing the action out. Office is on display, mobile computing too. Research has a corner – they always have fascinating stuff. Soon the crowd grows wearisome, however; after a last run through the food line, you get on the bus and head home. Another year at Microsoft. Another company meeting.

Time flies when you are having fun – how long until the next company meeting?