How Not to Give a Presentation

I hold speakers to relatively high standards. They get paid to present to large groups because they're ostensibly good communicators. And I cannot believe the beginner mistakes some of the speakers are making here at VSLive.

Based on my experiences over the last two days, here are a few sure-fire ways not to give a presentation:

1. Begin by establishing how impressive you are. Make sure we know all about your accomplishments and any books you've written. Be sure to plug your company and/or website. After all, this presentation is about you.

2. Present a detailed presentation agenda. Before you can get to any content at all, you must dutifully itemize the table of contents! You know how people love reading the table of contents. It builds suspense. It's exciting. It keeps the audience on the edges of their seats, wondering "when will I actually see any content in this presentation"?

3. Every slide should be absolutely jam-packed with information. Use as many bullet points and words on your slides as possible. Feel free to slap a few helpful URLs in there, too. If you can't fit it all on one slide, try a smaller font.

   

4. Explain everything with bullet points. Don't show the audience. Tell them. Avoid pictures or, even worse, actual demonstrations. Feel free to use several slides to properly explain things.

5. Read every word on your slides. Audiences can't read. It's your responsibility to do all the reading for them. But don't waste their time with a bunch of elaboration. Be succinct. Say exactly what is on each slide, then move on to the next slide.

6. If you make a mistake or something goes wrong, take a few minutes to fix it. The audience can wait. While you're fixing things up, try that NASCAR joke again. It's hilarious.

7. Use the highest possible desktop resolution. Show off your laptop's new widescreen LCD. Besides, limited resolutions and large fonts are childish and unprofessional.

8. Summarize everything at the end. Audiences are notoriously forgetful. Spend the last few minutes patiently recapping everything they just saw.

9. If you run out of time at the end of your session, keep going. The audience paid good money to see your presentation, so make sure they see it all. Your time is important.

10. Don't take any questions. The content and quality of your presentation speaks for itself.

This stuff would be funny if it wasn't happening every single day. Death by PowerPoint, indeed.

Presentation Magnification

Here at VSLive! 2006 San Francisco, I've been sitting through a lot of presentations. Unfortunately, I've spent a disproportionate amount of that time staring at tiny, unreadable 12 and 10 point IDE text.

Presenters, please don't do this to your audiences. If you can't pre-scale the font appropriately in the application, make use of one of the many automatic magnification utilities out there.

Heck, you can even use Windows XP's built in magnifier utility: Start, Run, Magnify.

The options for magnify.exe are limited but entirely servicable:

• It can automatically follow:
  • the mouse cursor
  • the keyboard focus
  • text editing
• Click and drag the magnification surface to move it. It can float as a window or it can dock to any side of the screen like the taskbar.
• Drag the corners to resize the surface.
• The magnification is adjustable from 1x to 9x.

In the screenshot above, I have the magnification window docked to the top of the screen. The IDE is maximized normally under it. Since magnify follows all my mouse and keyboard actions automatically, everything I do is now perfectly visible -- even from the last row of the room.

Not All Bugs Are Worth Fixing

One thing that continually frustrates me when working with dedicated test teams is that, well, they find too many bugs.

Don't get me wrong. I want to be the first person to know about any bug that results in inconvenience for a user. But how do you distinguish between bugs that users are likely to encounter, and bugs that users will probably never see?

The first thing you do is take that list of bugs from the testers and have yourself a triage meeting:

The term "triage" was borrowed from medical triage where a doctor or nurse has to prioritize care for a large group of injured people. The main job of a software bug triage team is to decide which bugs need to be fixed (or conversely, which bugs we're willing to ship with).

Eric lists four questions that need to be answered during triage to decide whether a bug should be fixed or not:

1. Severity: When this bug happens, how bad is the impact?
2. Frequency: How often does this bug happen?
3. Cost: How much effort would be required to fix this bug?
4. Risk: What is the risk of fixing this bug?

Triage isn't exactly my idea of a good time. But you have to do it, because you'll always have far more bugs than you have development time. Nobody has the luxury of fixing all the bugs in their software.

Testers produce two kinds of bugs:

1. A small subset of very serious bugs that everyone can immediately agree on. These are great. They're the kind of catches that make me thank my lucky stars that we have dedicated testers. You go, girl-slash-boy!
2. Everything else. A vast, gray wasteland of pseudo-bugs that nobody can really agree on. Is it an inconvenience for the user? Would users really do things this way? Would a user ever run into this? Do we even care?

It's a clear win for the bugs everyone agrees on. That's usually about ten to twenty percent of the bug list in my experience. But for everything else, there's a serious problem: testers aren't real users. I'd give a bug from a customer ten times the weight of a bug reported by a tester.

The source of the bug is just one factor to consider. Bug triage isn't a science. It's highly subjective and totally dependent on the specifics of your application. In Bugs Are a Business Decision, Jan Goyvaerts describes how different triage can be for applications at each end of that spectrum:

Last July I flew to Denver to attend the Shareware Industry Conference. I flew the leg from Taipei to Los Angeles on a Boeing 747 operated by China Airlines. This aircraft has two major software systems on board: the avionics software (flight computer), and the in-flight entertainment system. These two systems are completely independent of each other, developed by different companies, to different standards.

The avionics software is the software that flies the plane. No, the pilots don't fly the plane, the flight computer does. How many bugs would you tolerate in the avionics software? How many do you think Boeing left unfixed? How many people have ever been killed by software bugs in modern airliners? Zero. A flawed flight computer would immediately ground all 747s worldwide. Boeing would not recover.

The in-flight entertainment system is a completely different story. It's not essential to the plane. It only serves to make the passengers forget how uncomfortable those economy seats really are. If the entertainment system barfs all over itself, the cost is minimal. Passengers are already out of their money, and most will choose their next flight based on price and schedule rather than which movies are on those tiny screens, if any. I was actually quite pleased with Chine Airlines' system, which offered economy passengers individual screens and a choice of a dozen or so on-demand movies (i.e. each passenger can start viewing any movie at any time, and even pause and rewind). That is, until the system started acting up. It locked up a few times causing everybody's movie to pause for several minutes. Once, the crew had to reboot the whole thing. That silly Linux penguin mocked me for several minutes while the boot messages crept by. X11 showed off its X-shaped cursor right in the middle of the screen even longer. Judging from the crew's attitude about it, the reboot seemed like something that's part of their training.

Bugs also cost money to fix. In My Life as a Code Economist, Eric Sink outlines all the decisions that go into whether or not a bug gets fixed at his company:

Don't we all start out with the belief that software only gets better as we work on it? The fact that we need regression testing is somehow like evidence that there is something wrong with the world. After all, it's not like anybody on our team is intentionally creating new bugs. We're just trying to make sure our product gets better every day, and yet, somewhere between 3.1.2 and 3.1.3, we made it worse.

But that's just the way it is. Every code change is a risk. A development cycle that doesn't recognize this will churn indefinitely and never create a shippable product. At some point, if the product is ever going to converge toward a release, you have to start deciding which bugs aren't going to get fixed.

To put it another way, think about what you want to say to yourself when look in the mirror just after your product is released. The people in group 2 want to look in the mirror and say this:

"Our bug database has ZERO open items. We didn't defer a single bug. We fixed them all. After every bug fix, we regression tested the entire product, with 100% code coverage. Our product is perfect, absolutely flawless and above any criticism whatsoever."

The group 1 person wants to look in the mirror and say this:

"Our bug database has lots of open items. We have carefully reviewed every one of them and consider each one to be acceptable. In other words, most of them should probably not even be called bugs. We are not ashamed of this list of open items. On the contrary, we draw confidence from this list because we are shipping a product with a quality level that is well known. There will be no surprises and no mulligans. We admit that our product would be even better if all of these items were "fixed", but fixing them would risk introducing new bugs. We would essentially be exchanging these bugs which we find acceptable for the possibility of newly introduced bugs which might be showstoppers."

I'm not talking about shipping crappy products. I'm not suggesting that anybody ship products of low quality. I'm suggesting that decisions about software quality can be tough and subtle, and we need to be really smart about how to make those decisions. Sometimes a "bug" should not be fixed.

To me, triage is about one thing: making life better for your users. And the best way to do that is to base your triage decisions on data from actual usage -- via exception reporting, user feedback, and beta testing. Otherwise, triage is just a bunch of developers and testers in a room, trying to guess what users might do.

VSLive! 2006

Since Vertigo is in the bay area, and VSLive! 2006 is at the Moscone Center in San Francisco, a lot of Vertigites* will be in attendance from Monday to Wednesday. Including myself.

I was disappointed at PDC '05 that I barely had a chance to meet anyone. I don't want to make that mistake again. All you bloggers need to post your pictures so we can actually recognize each other amongst the sea of other middle-aged white guys. And, you know, talk**. About how to solve the Rubik's Cube and other random geekery.

Anyway, my picture is on my about page. Feel free to email me if there's a particular place or event people are meeting. And if you see me, holla back.. yo?

* I just made this up.

** Although I don't think Richard Hale Shaw is too anxious to meet me.

Google is the Help Menu

Jensen Harris recently cited some Microsoft Office usability research which produced a rather counter-intuitive result:

One of the most interesting epiphanies I've had over the last few years seems on the surface like a paradox: "help" in Office is mostly used by experts and enthusiasts.

How can this be? I think my biased assumption was that experts know how to use the software already and eager novices would be poring over the documentation trying to learn how to be more effective using it.

Yet, in usability tests we see it again and again: novices and intermediates click around and experiment, experts try to reason things out and look them up in help.

Dispelling myths based on actual usability data. I love it. Jensen offers a few potential explanations for this phenomenon:

• Only experts know the right "magic words" to search for.
• Users need a broader scope of help: not a recipe, but a community college course in cooking.
• Help requires a context switch-- it's difficult to look at help side-by-side with the software.

While there's definitely merit to these observations, Jensen misses the biggest one. You need only read through a few of the many post comments to see what it is:

It's been my experience that Office help often doesn't include anything useful, so I don't use it. For example, I was using Access and somehow became aware of the DoCmd object. It seemed like it would do what I want, but there is no help for it. How could this object with 100 different features have no online help? Luckily Google came to the rescue, pointing me directly to the microsoft.com page telling me all about it. Why wasn't the included in the help originally?

I once found an Excel function in the help that required I install one of the add-in tools to use it, but the help didn't mention this add-in at all. So I did a google search and found out what I needed to do to use this function.

I have to agree that the online help in Office is not the best. It is a great product, but when I need help I usually give up after examining the first 50 hits and the move directly to Google.

Regarding relevance, I would suggest adopting Google's algorithms for ranking. A Google search for "Excel operators" yields what I was looking for ("About calculation operators") as the second hit from Microsoft, with another relevant document (differences between 1-2-3 and Excel operators) being first. Excel 2002's help gives rankings 4 and 14 respectively, with most of the other hits having nothing whatsoever to do with operators.

I practically never use online help. However, I literally live and die by Google Groups. I am almost never the only person to encounter a problem or misunderstand a feature and Google Groups usually proves a much faster route to success.

I have stopped using help in Office and just rely on Google. The replies are more relevant and better sorted, and it's faster. Even if the answer turns out to reside on the Office Assistance site, it's easier to find it there with Google.

It seems to me that the best "help file" for your software is no help file at all. It's a GoogleMSN Search query.

Local help simply can't compete with internet search. I'll go even further-- if you are building local help files for your application, you're wasting your time. And more importantly, you are wasting your users' time.

Smart developers will stop wasting time on useless local help and build community around their product on the internet. One of my favorite examples of this is http://www.regular-expressions.info. It's the top hit for a Google search on the term "regular expressions". The author, Jan Goyvaerts, is also the author of RegexBuddy, a fantastic regular expression tool. The tool is great, but when I need help with my regular expressions, I don't bother with the local help file. I just type what I'm looking for into MSN Search and bring the full weight of billions of dollars of search optimization to bear on the entire internet. If I happen to be offline, Jan has thoughtfully provided both PDF and CHM versions of the content on regular-expressions.info.

Local help seems rather quaint in comparison.

This kind of online community can easily be linked from the UI, too. One of the few generally helpful "help" features is contextual point-and-help -- eg, clicking on a "what the heck does this do?" button. But even those should spawn generic search engine queries to be truly useful.

If you really want to help your users, set up a wiki for your product. Set up forums for them to participate in. Become an impartial nexus for all information related to your product, whether your company wrote it or not. And most importantly, have the guts to give your users control over these sites. You may have written it, but they have to live with it.

Visual Design Patterns

A recent post by Steve Makofsky reminded me that the excellent UI Patterns and Techniques site is now a book from O'Reilly -- Designing Interfaces.

There's technically no reason to buy a book on visual design patterns when you can find the same information online ..

• GUI design patterns
• UI Patterns and Techniques
• The GUI Gallery
• The GUIdebook

.. but what a glorious, infinitely browsable full-color book this is. It's highly visual and truly does justice to the concept: a Design Patterns for the eye instead of the mind. Sometimes atoms are better than bytes.

Unlike any of the Design Patterns in that famous book, these patterns are visible to your users. Plan accordingly.

Dependency Avoidance

Have you ever worked with developers that were charter members of the third-party-control-of-the-month club? You know the kind-- they never met a third party control they didn't like. They spend all day trolling downloads and experimenting with every tool listed on The Daily Grind. Which means deploying your solution is now a tricky balancing act of obtaining and installing the proper license files from a half-dozen different control vendors. Who all do things slightly differently. Oh, and don't forget to make sure the versions of all your controls are all up to date with the latest bugfixes, too.

These are also the kind of developers who are prone to adopt giant, complex frameworks just to get tiny additional bits of functionality. If you're not careful, your entire project is liable to come down with a severe case of frameworkitis.

I, on the other hand, think anything outside the base framework is guilty until proven innocent. I'll adopt third-party code, but as little as I can get away with, and only if it offers significant, proven benefit to the problem I'm working on. I've been burned too many times. My code may suck, but it's a constant level of sucking that I can plan around.

That's why I was heartened to read Joel's account of how the Excel team aggressively avoids dependencies:

When I was the program manager in charge of the first implementation of Visual Basic for Applications, I put together a careful coalition of four, count them, four different teams at Microsoft to get custom dialog boxes in Excel VBA. The idea was complicated and fraught with interdependencies. There was a team called AFX that was working on some kind of dialog editor. Then we would use this brand new code from the OLE group which let you embed one app inside another. And the Visual Basic team would provide the programming language behind it. After a week of negotiation I got the AFX, OLE, and VB teams to agree to this in principle.

I stopped by Andrew Kwatinetz's office. He was my manager at the time and taught me everything I know. "The Excel development team will never accept it," he said. "You know their motto? 'Find the dependencies -- and eliminate them.' They'll never go for something with so many dependencies."

In-ter-est-ing. I hadn't known that. I guess that explained why Excel had its own C compiler.

By now I'm sure many of my readers are rolling on the floor laughing. "Isn't Microsoft stupid," you're thinking, "they refused to use other people's code and they even had their own compiler just for one product."

Not so fast, big boy! The Excel team's ruggedly independent mentality also meant that they always shipped on time, their code was of uniformly high quality, and they had a compiler which, back in the 1980s, generated pcode and could therefore run unmodified on Macintosh's 68000 chip as well as Intel PCs. The pcode also made the executable file about half the size that Intel binaries would have been, which loaded faster from floppy disks and required less RAM.

"Find the dependencies -- and eliminate them." When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.

The .NET Framework was intended to be the dependency to end all dependencies. It's huge. It's also comprehensive and generally well-written. Any time you're reaching outside the framework for a giant swath of functionality, pause first and think about what you're trying to accomplish. Before you start stacking dependencies on top of the mother of all dependencies itself, make sure what you're getting justifies that risk.

Is it possible to take dependency avoidance too far? Of course. The flip side of reducing dependencies too aggressively is the Lava Flow anti-pattern:

As we delved into it, we interviewed many of the developers concerning certain components of the massive pages of code printed out for us. Over and over again we got the same answer, "I don't know what that class is for, it was written before I got here." We gradually realized that between 30 and 50% of the actual code comprising this complex system was not understood or documented by any one currently working on it. Furthermore, as we analyzed it, we learned that the questionable code really served no purpose in the current system, rather it was mostly there from previous attempts or approached by long-gone developers. The current staff, while very bright, was loath to modify or delete code that they didn't write or didn't know what it did for fear of breaking something and not knowing why or how to fix it.

I've never had a problem with lava flow because I am pathologically addicted to deleting code. I'm not afraid to get all Strunk and White on that codebase. I don't care if it woulda, coulda, shoulda been used-- is it being used right now? No? Then it's gone. Period. If you need it back, well, that's why God invented source control systems.

I'm not against dependencies. Everything software developers do is one giant string of dependencies. I'm a pragmatist. Strive to make your dependency stack as small as you possibly can.

.. and a Pony!

From the "why I don't read Robert Scoble any more" department:

One thing I wish is that Web site developers/designers would look at their site on a small screen with limited bandwidth. So many sites suck really bad. I'm going to call these sites out with increasing frequency in 2006.

If your site makes you scroll for 20 minutes just to see your content, it sucks. It'll get called out.

If your site squeezes a column so that it's only one word wide, it sucks. It'll get called out.

My wish? Please try your site on a cell phone (tonight I was comparing sites on a Treo, on a Blackbery, and on my phone. My phone was best, but there were lots of sites that sucked on all three).

Millions of Web users are out there with cell phones. If you don't get your site to work properly with a cell phone, you're turning away customers and that sucks. It'll get called out.

You know, it would be nice if every single website was designed to scale perfectly across all resolutions from 176x220 to 1920x1440.

It'd also be nice if trees were made of cotton candy, and rain was delicious lemonade.

This is what I refer to as ".. and a Pony!" thinking: the person asking the question doesn't know that what they're asking for is essentially impossible. So you might as well throw a Pony in there while you're at it. Everyone loves Ponies.

I don't mean to single Robert out here. I'm sure he's a nice guy, but he's the absolute poster child for this phenomenon; it comes up over and over again in his blog.

It'd be helpful if he actually offered any thoughts on exactly how one would go about implementing a web site that scales up seamlessly seventy times in resolution. But why explain yourself when you can just use magic?

Code Reviews: Just Do It

In The Soft Side of Peer Reviews, Karl Wiegers starts with a powerful pronouncement:

Peer review -- an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities -- is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.

After participating in code reviews for a while here at Vertigo, I believe that peer code reviews are the single biggest thing you can do to improve your code. If you're not doing code reviews right now with another developer, you're missing a lot of bugs in your code and cheating yourself out of some key professional development opportunities. As far as I'm concerned, my code isn't done until I've gone over it with a fellow developer.

But don't take my word for it. McConnell provides plenty of evidence for the efficacy of code reviews in Code Complete:

.. software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:

• In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
• In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
• The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
• IBM's 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
• A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
• Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.

The only hurdle to a code review is finding a developer you respect to do it, and making the time to perform the review. Once you get started, I think you'll quickly find that every minute you spend in a code review is paid back tenfold.

If your organization is new to code reviews, I highly recommend Karl's book, Peer Reviews in Software: A Practical Guide. The sample chapters Karl provides on his website are a great primer, too.

3D positional audio and HRTFs

I've always been fascinated with 3d positional audio through headphones. The nice thing about headphones is that they don't bug your neighbors or your wife-- and they're actually the best way to hear surround sound, too:

But for some surround sound, particularly 3D positional computer audio, headphones can actually work better than speakers.

The reason for this is that you've only got two ears. The way you tell whether a sound's in front, behind or above you, rather than just to your left or your right, is by processing the complex differences in phase, time delay and frequency balance that're imparted to differently located sounds by nearby objects (like walls), and by the sonic characteristics of your head.

Your pinnae - the outer parts of your ears - strongly influence sound waves that pass through and bounce off them. 3D game audio uses Head Related Transfer Function (HRTF) algorithms to fake the effects of the pinnae, the head and various listening environments, so that injecting the sound straight into the ear canal can produce the impression of real 3D audio sources.

When you've got HRTF-massaged two-channel audio already, for instance when you're playing a game, headphones are obviously the best way to get the sound into your head. There's no way for speakers to do the job as well, because there's no way for them to stop each ear hearing the sound that's intended for the other.

There's a long history of audiophile interest in stereo and binaural recordings, but 3d sound on a computer is a bit different:

1. Monaural sound is a recording of a sound with one microphone. No sense of sound positioning is present in monaural sound.
2. Stereo sound is recorded with two microphones several feet apart separated by empty space. Most people are familiar with stereo sound; it is heard commonly through stereo headphones and in the movie theater. When a stereo recording is played back, the recording from one microphone goes into the left ear, while the recording from the other microphone is channeled into the right ear. This gives a sense of the sound's position as recorded by the microphones. Listeners of stereo sound often perceive the sound sources to be at a position inside the listener's head -- that's because humans do not normally hear sounds this way, separated by empty space. The human head should be there acting as a filter to incoming sounds.
3. Binaural recordings sound more realistic, as they are recorded in a manner that more closely resembles the human acoustic system: with the recording microphones embedded in a dummy head. Binaural recordings sound closer to what humans hear in the real world; the dummy head filters sound in a manner similar to the human head.
4. 3D sound attempts to take binaural recordings one step further by recording sounds with tiny probe microphones in the ears of a real person. These recordings are compared with the original sounds to compute the person's head-related transfer function. The HRTF is a linear function that is based on the sound source's position and takes into account many of the cues humans used to localize sounds. The HRTF is used to develop pairs of finite impulse response (FIR) filters for specific sound positions; each sound position requires two filters, one for the left ear, and one for the right. To place a sound at a certain position in virtual space, the set of FIR filters that correspond to the position is applied to the incoming sound, yielding spatial sound.

Your ear shape (a.k.a. your pinnae) has a dramatic effect on how you hear sound. But don't take my word for it -- hear it for yourself. The 3D hearing test page has a binaurally recorded sound sample using eight different ear shapes.

You can hear your PC sound card perform HRTFs using RightMark's 3DSound Positioning Accuracy test. Note that you must switch to DirectSound3D Hardware mode (or better) via the System menu to hear anything more than stereo positioning!

If your card supports EAX modes, try those too. However, when using EAX, make sure you switch to the "plain" environment for apples-to-apples testing. For some reason it defaults to "generic", which colors the sound a bit.

HRTF functions magically convert stereo sound into 3D sound, but they are computationally expensive. That's probably why DirectSound Software mode offers no HRTFs. You need an add-in sound card with hardware acceleration to achieve 3D sound with headphones. The first PC sound card to offer 3D positional sound was the Aureal Vortex via the A3D API circa 1998. I was a huge fan. But unfortunately, Aureal isn't around any more.

So called "onboard" sound -- the kind you get on your motherboard for free -- has improved, but it generally has lower sound quality than a dedicated sound card, and it's certainly not capable of meaningful hardware acceleration. Onboard sound is simply not an option if you're a gamer of any kind. Although I grudgingly installed Creative sound cards in my PCs after the demise of Aureal, it was only because I had no other viable options. I always felt that Creative's 3D sound HRTF algorithms were never as good as Aureal's. Creative's new X-Fi sound cards, however, are finally poised to change that. For one thing, they have a lot more horsepower:

Sound Blaster Live!	1998	2 million transistors
Sound Blaster Audigy 2	2002	4.1 million transistors
Pentium 4 "Northwood" 2.0GHz	2002	55 million transistors
Sound Blaster X-Fi	2005	51 million transistors

The X-Fi sound cards are also comically overpriced. Three hundred bucks for a sound card? But the lowest-end model, the X-Fi XtremeMusic, sacrifices almost nothing compared to the fancier models and is priced within reason at around $110 online. That's still double the cost of an Audigy 2, but unlike the last umpteen zillion Creative sound card "upgrades", you get a much more powerful card this time with some truly useful new features:

• Up to 128 simultaneous sounds
• Vastly improved CMSS-3D headphone HRTFs
• Real time Smart Volume Management aka dynamic range compression
• Real time upsampling of 16-bit sound to 24-bit

If you're looking for performance improvements over an earlier Sound Blaster card, there are none. It's just more functionality with no performance loss. For more details, check out Extremetech's review of the X-Fi by my pal Loyd Case.

I've been testing the X-Fi with Battlefield 2. It's one of the only two games that explicitly supports the new card's features at the moment (the other being the execrable Quake 4). I always play with headphones, and I noticed the improved 3D sound HRTFs immediately. The sound is also much richer with 128 voices; it's easy to exceed the previous limit of 64 simultaneous sounds in large multiplayer games. I'm very impressed. I also tried the card with Doom 3 using the 1.3 EAX patch and noticed similar improvements.

Although the X-Fi is a wee bit spendy, I can heartily recommend the basic model to fans of 3D audio and headphones. And if you want a clean, non-cluttered install, don't bother with the CD in the box. Just download the latest X-Fi drivers from Creative's website and install those instead.

The Creative Audio Console comes with the base driver, and it's all you need to configure the card.