Marc McDonald on Channel 9: Watch it!

Martin Dittus · 2005-09-10 · commentary, links, reviews · write a comment

After the recent Ballmer debacle I merely glanced at a screenshot of the Channel 9 interview with Bill Gates, and downloaded the interview with Marc McDonald instead. This turned out to be a good decision.

Most of the Channel 9 interviews by now are product presentations, but occasionally there are real gems that should be mandatory viewing for everybody in the field. The sessions with Bill Hill about Typography, human perception and interfaces are such gems (see links below). This session with Marc McDonald is of near Bill Hill-level quality, but admittedly on a subject that is a bit more esoteric.

Marc McDonald apparently was Microsoft's first employee ever, before he went to other comanies and returned in 2000. After reading this I expected him to be a blasé billionaire in a business suit, but in reality he's simply a standard down-to-earth Microsoft geek who's still excited about his field of work. And he works in a pretty geeky domain too: Windows Defect Prevention.

According to McDonald, the Defect Prevention team started out with general methods of root cause analysis to find root causes of bugs, then found that this didn't scale enough, causing "months for someone to go over a hundred or so bugs and figure out what the root cause was", so over time their toolkit of methods grew into areas as diverse as statistics and human psychology.

Basically, they're trying to find and apply a mix of solid engineering methods to a problem domain that is per definition volatile.

He mentions James Reason (I did not make that name up), a Psychology professor who studies the nature of human error: what kind of errors do people make? And why? There is a paper by Reason called "Human error: models and management", and a paperback titled simply "Human Error", of which I quote the Amazon book description:

Modern technology has now reached a point where improved safety can only be achieved through a better understanding of human error mechanisms. In its treatment of major accidents, the book spans the disciplinary gulf between psychological theory and those concerned with maintaining the reliabiblity of hazardous technologies. Much of the theoretical structure is new and original, and of particular importance is the identification of cognitive processes common to a wide variety of error types.

Then he mentions orthogonal defect classification, a statistical method and classification system pioneered at IBM. There is a introductory paper on ODC called "Orthogonal Defect Classification - A Concept for In-Process Measurements", and a nice quote on the IBM research site:

ODC is a scheme to capture the semantics of each software defect quickly. It is the definition and capture of defect attributes that make mathematical analysis and modeling possible. Analysis of ODC data provides a valuable diagnostics method for evaluating the various phases of the software life cycle (design, development, test and service) and the maturity of the product. This is much like the diagnostics done in medicine using the blood sample from a patient to understand the existing health conditions and arrive at corrective actions. ODC makes it possible to push the understanding and use of defects well beyond quality.

Marc then created a defect taxonomy that integrates the statistical classification systems with aspects of human error analysis. He realizes that there is no value in blaming an individual developer for an error when there can be a variety of causes leading up to that error, from technical causes to human error which often finds its root in the mere complexity of the systems that are being worked with. (McDonald: "Knowledge access needs to be a priority.")

Then Scoble interrupts with his first real question.

Scoble: Is it possible to make a perfect piece of software?

McDonald: It's possible to make software that is a lot better. But perfect is... based on the definition. What's perfect? It's like proving correctness: OK, it does what you say, but is what you say right?

Scoble: But isn't software a creative endeavor, like taking a photograph or drawing a picture, or writing a great poem?

McDonald: The way I phrased it in some papers is saying, software is making dreams reality. In a way what we're doing is, we're taking someone's idea, some user's or customer's, and turn that into reality. And that's a translation process. You're going from this nebulous idea to a more concrete expression of the idea, then you start putting it into code. All these are translations. Every time you have a translation you can make an error, or you could lose information. So that what you have in this level just isn't expressible in the level below that.

Lovely. You could illustrate nearly every sentence with one of the Joel on Software essays, but I won't go into that.

Also interesting: Marc's recollection of Design Intelligence, who did adaptive content design software (before they got bought by Microsoft in 2000), which means they developed CMSs that are capable to adapt content design to changing requirements and formats, and still "do the right thing", deliver a result that is satifying to the designer. Here the translation process is between the designers and the developers who create the system, and between the designers and the software itself:

One part of the learning experience in that was that the designer's life is that result. That's how he is judged: by how it looks like. That's why they're very fine at this. 'Not this font, that font. Well.. not 8 point, 8 point 3 is better. And the leading should be just two tenths of a point bigger than that. Oh and I want to expand the kerning by half a percent between characters.' They're very precise sometimes. And you're asking them to give up that control.

So in order to do that you have to understand their concepts and reflect them. I could come up with the most elegant technical way to do layout or positioning or font-sizing or anything, if they didn't grok it it don't fly. You have to satisfy that customer, because you gotta get their buy-in, and you're not going to get it if you do things that surprise them. So least astonishment is what you needed to do. And that's the hard part of what we call doing an expert sytem: understanding the expert, their concept. So I would spend hours and hours and days with designers, saying 'Let's talk about this particular issue.'

Say, emphasis. You might think emphasis is just size, well yeah, is it width, is it height, change the aspect ratios, black and white versus color, position on the page, does it have a border, how much whitespace is around it, all those things affect emphasis. And yet, as a developer you might think 'Ahh, it's just size.'

These are just short extracts from the beginning of the video, there's also some looking back at the starting points of the IT industry, a look at McDonald's book shelf with some book recommendations (I'll put this one on my wishlist), and other stuff.

Scoble sucks as an interviewer as usual, because he constantly interrupts interesting anecdotes with offtopic questions, and at one point he nearly wants to stop MacDonald praising the iPod product design because it's from Apple, not Microsoft. Marc is noticeably less interested in politics: "You have to recognize a good idea, no matter where it comes from. You have to give credit where credit is due". (Scoble, semi tongue-in-cheek: "I keep expecting Steve Balmer walking around the corner!")

And then this. Scoble, asking McDonald about highschool-mate Bill Gates: "What is it about his mind that lets him... see things?" Boy. Microsoft really screws with your mind. Apple has reality distortion, MS has their own version of Guru syndrome. Luckily Marc sidesteps the question, and talks about personality types instead, about quick thinking, synergy, and about how he likes to work with a rigorous person who grounds his own "visionary" excitement.

Anyway. Go forth and watch the video. Caution: huge download.

Related Links


Next article:

Previous article:

Recent articles:

Comments

Comments are closed. You can contact me instead.