TexBlog

Sean Nordberg, Daniel Moth, and I sat down with Charles earlier this week to talk about tooling for building parallel apps and show of some of the things we're working on for Visual Studio.  If you'd like to learn more, we'll be presenting at both PDC and TechEd Europe over the next month, and we'd love to see you there! At PDC, in addition to regular sessions, we are also hosting a pre-conference tutorial and a post-conference symposium, so -- as the advertisement goes -- if you're only going to one conference this year... make it PDC. :)

InformIT just posed a new video (part 1, part 2, part 3) in their OnMicrosoft series in which Steve Toub and I chat with Ted Neward about parallel computing.  I just watched some of it, and I was pleased to observe that Steve and I don't look like total dorks.  Aside from them repeatedly misspelling my name during the video, I hope you'll find it interesting and informative if not dramatic and gripping.  :)

I had an opportunity to chat with Carl and Richard of .NET Rocks! fame recently about the future of parallel computing on the client and some of the near-term technologies we're building on the Parallel Computing Platform team.  Listen in and let me know what you think.

A little preamble: this blog entry may win some sort of infamy award for sitting in my Live Writer drafts folder since late June.  Dang, time sure does fly.  Anyhow, the irony of sitting on a blog entry for for three months doesn't escape me, but what the hell... I'm posting it anyway.

I was on the road with my colleague, Keith Yedlin, last month for the International Supercomputing Conference in Dresden followed by Parallel Computing Initiative presentations in Paris.  Keith manages the sibling product unit to mine, developing the platform and programming model components for Parallel Computing, such as the Parallel Extensions to the .NET Framework, while I manage the Visual Studio tooling that complements new and existing parallel programming models. 

At ISC08 we continued to commune with the Supercomputer community and with members of the Microsoft field and product teams focused on Windows HPC Server.  There is an interesting continuum in parallel computing... my team occupies mostly the middle portion of that continuum with multi/many-core computing experiences on the client, the high end of the continuum is occupied by HPC/cluster computing, and at the low-power end you'll find handheld devices with multi-core CPUs and systems-on-a-chip.  ISC gave us an opportunity to explore the overlapping chunk of the client and cluster ven diagrams and how we can create experiences for developers and users that scale easily between the two.  One of the more interesting things I took away from my conversations with customers and industry folks was that the need for sane and lovable programming models exists both on a multi-core client and on individual nodes of a cluster (which are now also multi-core and must deal with shared-memory parallelism on the node).

From Dresden, Keith and I stopped briefly in Paris to deliver presentations on the Parallel Computing Initiative and Parallel Computing Platform technologies to internal-to-Microsoft as well as external audiences.  Upon arriving to Paris, and not being sleepy after being on the go all day, we elected to go for a walk and maybe grab a drink.  We found ourselves in the park area behind the Eiffel Tower, and, man, it was PACKED! "Cool," we said to ourselves.  "Must be a concert going on or something." As we wade through the wall-to-wall young people, we see little fireworks shoot into the air and then observe crowds of folks running away from the arcing fireworks.  Except these are pretty meager fireworks; they don't really go bang and they seem to get unnecessarily smokey when they land.  As the crowd of fireworks-runners go past, we observe what they're running from: police in riot gear marching forward.  And as our eyes and noses begin to sting we realize that what we thought were little fireworks being launched by happy-go-lucky folks in the park are actually tear gas canisters being launched by the stern looking cops in decked out in riot gear.  We had stumbled into the middle of a quaint little gathering of students celebrating completion of end-of-year exams just as the local authorities decided it was time for them to go home.

So, yeah... never been tear gassed before, so that was cool.

Anyhow, we managed to find our way back to the hotel without being swept up in the dragnet.  Presentations the next day went really well, with lots of excitement about the parallel computing experience we're creating for developers from both the local Microsofties and the external organizations and press that stopped by.  Our presentation even earned us some ink in the French press (multi-coeur, how cool is that?) -- ink with a hint of sarcasm in this case, but I totally get that the proof what we're doing will be in the pudding, and it's crucial that we deliver on the promise for making the construction of parallel software dramatically simpler.

The indefatigable EricMitt has posted the videos from our presentation in Paris (you'll be treated with presentations in English if you can make your way through a little bit of French UI).

Having been on the job for a few months now, I feel like the team and I are finally beginning to settle in.  It's been a period of significant flux for the Parallel Developer Tools team that included a new leader and (largely) new team trying to adjust to one another, building a plan for the next release of Visual Studio, recruiting and hiring top talent for the team, physically moving to a new building on a different part of campus (and separate from most of the rest of VS), building and strengthening partnerships with teams internal and external Microsoft to drive the Parallel Computing Initiative forward, and, and, and...

I came across this InfoWorld article today regarding developer skills and parallel computing.  I was amused the fact that the issues raised by Dan Reed in the article echoed a conversation I had with Dan just yesterday when I met him for the first time in his office (which happens to be just across the street from mine).  It's a fact that developers largely really are not (yet) trained for parallel computing.  What's more, those that are trained typically have their experience base in high performance computing (think massive amounts of data being crunched on clusters), which is a slightly different problem than that we're trying to deal with on the PCP team.  Our focus in more squarely on leveraging the increasing parallel-capable hardware of a single node, typically a client PC running Windows, and dealing with the complexities of shared memory, making existing software more parallel-scalable, and how we'll design next-generation, inherently parallel software, and -- of course -- how to make parallelism second nature to current and future developers.

By the way, I should mention that I'm looking for the industry's best developers, testers, and program managers to assist us in this effort.  Here are some of the current job openings on my team:

Lead Software Development Engineer

Software Development Engineer

Group Program Manager

Software Development Engineer in Test

Software Development Engineer in Test

No, not that PCP.  The PCP to which I refer is the Parallel Computing Platform, a fairly new organization within Developer Division that is working to unlock new experiences for PC users by making it much, much easier for developers to build applications that leverage the opportunities for parallelism afforded by new multi-core CPUs.  Read more on the coming shift to parallel computing and what it means for developers in this Microsoft white paper and Herb Sutter's The Free Lunch is Over article from Dr. Dobb's Journal.

Yes, this means I've moved on from the Visual C++ team.  In my new role I'll be serving as Product Unit Manager for the Parallel Developer Tools team within the PCP organization.  My team is focused on the tooling developers need to build highly parallel software, such as debuggers, profilers, analysis, and designers.

So how can you be on PCP? You can start by visiting our Parallel Computing MSDN dev center.  If you're really ambitious, you can start playing with our Parallel Extensions to .NET 3.5 CTP.  Of course, there's more where that came from, and in the coming months you can expect to see things like parallel development libraries and tools for both native and managed code developers.

I'm late in getting this blog entry out, but I wanted to do a quick recap of the Visual C++ team's trip to TechEd and follow-on trip to Munich.  As I mentioned previously, my talk on debugging in VC++ 2008 went well, and my audience was an unusually attractive bunch.  Ale Contenti and Kate Gregory also did VC++ talks, and in the final tally the VC++ talks scored very well based on both attendance and attendee survey results.  Count on more VC++ talks at future TechEds!

Kate and Ale also did a great chalk talk on TR1 and C++0x, the upcoming C++ standard.

Ale deemed TR1 to be "super cool" (which sounds better when you say it with an Italian accent), which is plenty enough an endorsement for me.

We also enjoyed our traditional dinner out with C++ MVPs and the VC++ folks.  We ate at Cal Pinxo on the harbor, which was fantastic, as evidenced by the happy faces you see here:

Truth be told, this wasn't an exclusive VC++ staff/C++ MVP event.  In the photo you will notice some sketchy looking MS France guys on the right and some friendly but distinctly non-C++ MVPs from Italy.  They all looked hungry, though, so we invited them along.  :)

Before leaving Barcelona we also took the opportunity to sit down with our friend Charles Torre for a Channel9 video on VC++ 2008 and beyond.

Munich

After TechEd, Ale and I jetted off to Munich for an action-packed few days of presentations, customer visits, and press interviews.  The MS Germany team that arranged our visit, including Dariusz Parys, Christian Binder, and Barbara Steiger, were awesome and definitely kept us busy!

Imagine, also, if you will the small matter of temperature shock upon leaving balmy Barcelona for this place:

Dariusz and Christian were also kind enough to record a couple of Ale's sessions, which you can find here and here.

All in all a great trip, but very tiring.  Not to mention expensive for a poor soul like me that earns his income in dollars.  :)

How big is TechEd? So big that they had to add additional capacity to the conference center here in Barcelona in the form of two vast portable session halls, lovingly referred to as "Tent1" and "Tent2." Yours truly was lucky enough to give his session on Debugging and Crash Dump Analysis in VC++ 2008 in Tent2 today.  I must say, it's the first time I've ever performed under the Big Top, but I hope it's not the last.  The circus life is for me!

I had the audience pose for a picture prior to starting my session.  Check it out:

Nice group, eh? I might add that this was clearly the most intelligent and downright attractive crowd at the conference.

There are tons of hidden gems in the debugger, so I tried to avoid the obvious stuff and focus on some of the power features as well as offer a discussion on how to avoid having bugs in the first place.  I had a good time, and I hope the audience did as well.  I do know at least one member of the audience found it useful; now, I don't read Italian, and I'm never one to toot my own horn, but I'm pretty pleased with Raffaele's assessment of "Magnifica la sessione." :)

Hey, long time, no blog.  I'm in TechEd this week along with Ale Contenti for TechEd EMEA.  Luckily, my trip was pretty much uneventful (if you don't count the up-close-and-personal wanding I received at SeaTac airport), and I even have my luggage, unlike last year.  If you're going to be at TechEd and want to chat, please drop me an email -- I'd love to meet up.  I'm speaking on Wednesday, and I'll try to be at the Visual Studio booth as much as possible otherwise.

Next week, we'll be in Munich for a series of Visual C++ customer meetings and events.  We'll be hosting an open public VC++ event on Thursday, November 15th at 6:00 PM.  See Dariusz Parys' blog for details -- I expect to see all you Bavarian C++ developers there!  :)

Interesting blog entry from my old friend and colleague Steve Trefethen on Microsoft APIs.  Steve brings up a lot of good points, and I particularly agree that the API landscape is way more fragmented and confusing than it should be, and we at Microsoft need to fix that.  However, I also come in on the opposite side of several issues Steve raises, so I thought it would be worthwhile to call out a few specific points.

It seems Redmond has one-upped Google by putting out alpha software and beta software with "Go Live" licenses. How long will it be before we see alpha software with a "Go Live" license? Are we to believe businesses today are betting their future on all of this pre-release code?

While I agree the proliferations of alphas, betas, CTPs, etc. can be confusing, I actually don't feel this is a bad thing.  Years ago, Microsoft (and the industry as a whole, for that matter) was much more secretive about project under development. These days, customers overwhelmingly prefer transparency, even knowing that transparency means working with software that has a few warts and is subject to change in shape and behavior.  The comparison with Google is also interesting because Google customers have clearly been very happy to use services that Google has deemed beta quality (Gmail, Maps, Toolbar, etc.).   Given the way folks are voting with their feet in favor of these things, a reasonable person could conclude that customers often find value in software even if it's not considered "RTM quality."

Is [an MSDN statement comparing WPF to GDI] implying that the new Office 11 Ribbon UI is "constrained? Ah, but it's  not .NET so it must be constrained. And what about Vista's fancy new albeit unmanaged UI surely that must be constrained right?

Nobody ever said that all things .NET were constrained.  The referenced quote was making a point that it's a great deal of work to build WPF-quality user interfaces with straight Win32 because Win32's GDI is old and crufty.  Of course you can build the Office ribbon and cool looking Vista apps in straight Win32, but the point is that it requires more effort than some of the alternatives.

Btw, where is Microsoft's developer support for the new Vista UI? That's not due to arrive until Orcas ships. Didn't the MFC guys know when Vista was going to ship? Or was it that it just didn't matter until recently?

Our bad.  While Developer Division was successful in launching .NET 3.0 technologies (e.g., WPF and WCP) with Vista, we did not deliver comprehensive tooling that enables developers to easily take advantage of the breadth of the platform.  Yes, the MFC guys (i.e., my team) knew Vista was coming.  We were just not agile enough to release such a product before Orcas.  However, making mistakes is also a great way to learn, and you can bet that future tools releases will have better schedule alignment with major platform releases.

It's almost as though the Microsoft factory is stuck on hyperdrive. They're competing with Linux, Apache, PHP, Flash, Eclipse, Java, Oracle/MySQL/DB2/etc, Google, Mozilla, Open Office, MySpace, Yahoo and over the past 12 months have released betas in nearly all of these areas.

I wouldn't say that we're in "hyperdrive." This is who we are.  We're the world's largest software company, we have broad product and business portfolios, and we're going to be very competitive in all of the markets we serve.  However, I do think it's fair to say that because of this broad scope, Microsoft is less technologically homogenized than in past years, which can mean a lot of different platforms with a lot of different APIs which can result in a lot of confusion.

Staying with Microsoft tools will undoubtedly mean moving to .NET...

No way, Jose! In fact, the Visual C++ team's primary focus is on the native Windows platform.  We have some very aggressive post-Orcas plans for advancing the state of the art of native development.  Our secondary focus, btw, is on native-managed interop, with the goal of enabling ISV-style applications to have their cake and eat it too by getting full value from their native code while still incorporating and benefiting from .NET technologies (or bringing together the Raymond Chen camp and the MSDN Magazine camp, to use Joel Spolsky's taxonomy).

I might also add that Olivier Giroux over at NVidia (who takes a wait-and-see approach to all of this new technology) intimates why native C++ code will always be important:

...I have to write cross-platform software by day...

In fact, many of our best C++ customers use C++ because it enables them to target almost any platform, whether it's consumer software on the Mac or server software on Linux or avionics software running in a jet fighter.  These customers require the portability and/or the runtime control offered by C/C++, but we do need to make sure they also have a development-time experience comparable to that of the managed code developer.

Does anyone know what will really happen to WinForms with WPF being touted as the new UI for Windows? Will there be an Interop WPF toolkit available to move your WinForms apps one form at a time to XAML/WPF?

I have a couple of thoughts on this: first, WPF does not currently have the features and capabilities necessary to supplant WinForms as the framework of choice for line of business style applications.  I know we've tried to message this appropriately, but I agree that it sometimes gets lost in the WPF enthusiasm.  Projecting down the road, I would ask: what are your expectations? If, some day in the future, WPF does overtake WinForms in terms of LOB capabilities, my expectation would be that we would continue to support WinForms for existing customers but recommend WPF for new code.  Or am I talking crazy talk here? Meanwhile, we do intend to support mixed WPF-WinForms apps in the Orcas release.  A WinForms to XAML converter is something I know people have talked about internally, but I expect customer demand would dictate what we do here.

The sad thing is that I'm actually interested in several of these technologies but the field is increasingly looking like the slide from Stephen Colbert's The New AT&T (see about 50 seconds into the video). I've been trying to keep up though it seems a lost cause with each passing day I'm falling further behind.

First, props for the pointer to Colbert's hilarious AT&T video! More seriously, my view on this is that the day has long passed where it is practical to keep up with every developer technology coming out of Microsoft.  Ten years ago, it was totally doable and expected that any "real" developer was totally on top of all of the new stuff coming out of Microsoft.  Today, software developers are more specialized.  A developer may focus on web applications or ISV-style native apps or LOB apps or mobile or SOAs or some industry vertical or some other spoonful of alphabet soup.  Or maybe even one or two of these.  After all, most of us have day jobs and the world of Microsoft platforms is so big that simply understanding it all to any reasonable level of depth would be a full time job in itself.

That said, I'm not going to hand-wave away the fact that there are areas where would do have overlap or should better aligned or must be better at messaging when and where to use what technology.  And we also need to better align platform and tools releases.  All of these things are true. But I don't believe it should be a fundamental goal to homogenize our platforms and APIs before letting anything out the door.

A number of news aggregators and blogs have picked up this Broadcasting & Cable story, reporting that HBO CTO Bob Zitter wants to stop referring to content securing technology as DRM and begin referring to it as DCE, for Digital Customer Enablement.  Are you kidding me?  Enablement?! Seriously.

Look, if you own content, you have every right to cripple protect that content however you see fit. I certainly won't debate that.  I also believe that companies that build platforms to host this content, such as Microsoft, Apple, TiVo, etc., must provide core technology to support the desires of content owners, even if those desires include DRM.

However, I'm also a big believer in free markets, and I'm confident that DRM'd content (at least in its current form, where the "D" in DRM could stand for Draconian) will ultimately lose in the market to companies distributing content in more convenient, customer-friendly formats.

But, all of this aside, don't try to make the rest of us use your weasel words.  DRM is not about customer enablement of anything.  It's about restricting what customers are already able to do in order to support a particular business model.  Again, I support a content owner's right to do this, but I will vote with my dollars for content owners with more customer-friendly approaches.

International readers, please bear with me while I get all North American-centric on you for a sec.  One of my favorite "business" books in recent years is Moneyball: The Art of Winning an Unfair Game by Michael Lewis.  On the surface, Moneyball is a book about baseball and specifically about my hometown team, the Oakland Athletics in the year 2002.  For the baseball fan reader, the book is full of great anecdotes about on-field heroics and front office intrigue.  However, below the surface Moneyball is all business.  It's a story about exploiting the inefficiencies in a market, about identifying metrics that directly correlate to success, and about buying low and selling high.

I had a Moneyball moment a couple of weeks back when a colleague and I were discussing "model" employees for a certain role.  As my colleague threw out a few examples that fit his model, I realized he was falling victim to "the good face" mentality described in Moneyball.  Lewis talks about baseball scouts referring to prospects as having "the good face" when they look the part of a major league baseball player: handsome and well built, preferably with a flair to their personality and game.  Of course, this is an utterly bogus consideration in terms of assessing a prospect's major league potential, but some scouts obviously gave it consideration because the Oakland Athletics organization exploited this market inefficiency by focusing on things like track record, college experience and just generally recruiting ugly, chubby guys that could play baseball.

Anyhow, I realized my colleague was falling into the trap of describing his idea of model employees for a role in terms of the attributes he thought someone in that role should have and how he felt they should behave, as opposed to in terms of the results someone in that role should achieve and their track record of successful results (note, by the way, that by "results" I don't simply mean "money" or "profit" but the full scope of metrics and attributes by which an individual's job performance is measured).

This Moneyball moment was a reminder to me be crisp about what success looks like and to let that vision of success inform my actions.  It's nice to do a really great presentation or to craft a particularly brilliant email, but unless it contributes to successfully accomplishing the goal, it's just the good face.

Remember the good old days, when a progress bar in the user interface actually provided an indication of, well, progress? Alas, today the progress bar devolved into little more than a dancing monkey, doing the electric slide back and forth in its tiny box in an attempt to simultaneously communicate to me that something is happening while also trying to distract me from from the fact that I'll be waiting some indeterminate period of time for that thing to finish.

In the beginning, progress bars made a credible attempt to demonstrate the percentage of completion of some particular task.  The movement of the progress bar wasn't always smooth -- it could linger on 25% complete a bit longer than 75% complete -- but it did provide a reasonable approximation of progress toward completing a task.

However, keeping the progress bar in general synchronicity with reality can be hard, so, over time, software designers began to give up.  Maintaining any semblance of accuracy or smooth motion in the progress bar became a distinct non-priority.  I remember my first exposure to this temporal dissonance while installing some software on Windows 95.  The user interface provided a few vague textual messages about what was happening as the progress bar ranged from about 0 to about 90%.  This took about 10% of the install's total time.  During the remaining 90% of the total install time, as the progress bar inched its way the last 10% to completion, the installer provided textual messages with ridiculous detail on what it was doing.  It's almost as if the point of the UI widget was to annoy rather than inform.  Alas, this form of progress bar remains the most common species found in the wild today.

Shamefully, a colleague pointed out to me a particularly egregious progress bar in Visual Studio today, where it takes about 15 minutes to get to 100% and then lingers on 100% for several hours.  Sigh.

And a particularly hideous offspring of the inaccurate progress bar is the one starts all over again from zero after it completes.  Sometimes more than once.  Oh, the humanity!

Anyhow... along came the web, which you might say forked progress bar behavior.  Something like a progress bar was pretty difficult to do accurately in HTML, particularly when things you'd normally want to use a progress bar for tended to involve the code on the web site merely firing a single request to some other server, with no hope of knowing the progress.  So instead of a progress bar, we got that progress-bar-appearing-thing-with-oscillating-Cylon-eye-motion.  I'll call it PATWOCEM.  The PATWOCEM's #1 goal is to encourage you not to navigate away to another web page by providing an indication that something worth waiting for is going on.  On some level it makes total sense: If you just display some text like "please wait..." people will get impatient after a minute or so.  However, add a PATWOCEM, and you probably increase their willingness to wait by a factor of at least 3x.  While the psychological effect is no doubt real, I can't help but be frustrated by its functional uselessness and the continued devolution of the progress bar.

The PATWOCEM has found its way from the web to the rich client in the form of the indeterminate progress bar, which is so common in Windows Vista.  I really do understand that this PATWOCEM is useful for cases where the overall progress cannot be determined, but I'm also confident that developers use this as a crutch when they don't want to do the bit of extra work involved in figuring out how to track progress of a given task.  C'mon, do the work! Your users will be happier! My crack research staff (okay, me) uncovered the design guidance on progress bars for Vista on MSDN.  The content is actually good.  If only more developers followed it.

No, it's not a code name for some cool, new developer tool.  It's what I found hanging out outside my window this morning.  Kinda cool.

Just had to share this.  We received this message via the feedback form on the VC++ team blog:

My text book says to make a simple program.

None of the new files have the option(simple program).

 

What would be the correct file?

A File|New|Simple Program wizard would indeed be handy! Probably second in usefulness only to the Project|Simplify wizard.  :)