Last year I had a marvelous time at Tech Ed Africa, and made the Top 5 list. I am thrilled to announce that I will be there again this year! It will take me about 41 hours to travel from my house to the conference center, and about 36 hours to get home a week later. This place is seriously far from home.

My talks:

Microsoft Visual C++ 2005: A Look at the New Features for Building Fast Native and Managed Code
Whether you build end-to-end applications or components for enhancing larger applications, the new Microsoft Visual C++ 2005 is the power tool for Windows programming. In this presentation we spend extensive time in the Visual C++ 2005 development environment -- highlighting new productivity features -- as we dive into its support for building high-performance, first-class native and managed applications. Learn about native code compiler optimizations, security enhancements, 64-bit development, and support for multiprocessor/grid computing systems. In addition, this presentation demonstrates how Visual C++ 2005 now provides CLR/.NET Framework support that allows it to stand toe-to-toe with any other tool in terms of elegance and productivity… with the additional benefit of high-performance access to native code and the ability to easily move native code to the managed environment.

Microsoft Visual Basic 2005: Application Frameworks and Advanced Language Features
This is a must-see session for Visual Basic developers who are new to Microsoft Visual Studio 2005, and also reviews the major feature changes and additions for beta 2. Take a top-down look at the new application architecture and RAD development enhancements in Whidbey, including several key productivity features that are exclusive to Visual Basic. This session covers the new Visual Basic lightweight application model for client applications, the My namespace, Data, Settings and Resources, and many more features that speed development for connected applications.

Windows Forms: Deploying Applications with ClickOnce
This session covers examples of ClickOnce deployment technology at work in the real-world as well as advanced scenarios, including an in-depth look at leveraging ClickOnce APIs for server-side extensions and on-demand deployment of application components.

Only two things could have made my trip last year better: an extra day to explore and soak in the marvelous place where this conference is held, and a friend from "home" to travel and explore with, to while away the long trip there and back. Can you believe I get both my wishes! I must be living right.

Oh, did you want to register? Too bad, it's sold out.

Kate

Gregory Consulting is in its 20th year of operation, and at the moment has six employees. I think it's fair to point out you can't stay solvent over that length of time, meeting payroll, paying rent and ISP fees, without some business sense. One of our most important rules is Fail Fast. If you're doing something that might not work, and it's going to fail, it is so much better to fail in the first week than in the sixth month. This leads to all kinds of useful practises like doing the risky bits first, prototyping, making little proof of concept apps or subapps, and the like. Note that we don't do these things because a Methodology said we should. We do them because our gut or some little voice in our head says “are you sure that's going to work?” and then our brain comes up with a way to fail fast. Of course not failing at all is better than failing, and these techniques can also put you in the delightful position of knowing it's going to work, and just having to write it.

Fail Fast and "let's try it" can also save you a ton of time spent arguing about what's the best way to do something. Last week, I was at a early code review of an partly-written ASP.NET 2.0 application where someone had put some DataSet instances into Session even though they were used only on a single page. I wanted them in ViewState, because sessions expire and you have some hoops to jump through to ensure the work won't be lost. One developer on the team said putting things in ViewState made your pages too big. I said that wasn't an issue for the amount of data in this app. After about ten minutes of "what if someone pulls up the whole department for a year?" back and forth we decided to just try it. It took 30 seconds to flip the code between using Session and using ViewState. And guess what? After disabling viewstate on the grid, which was making both versions of the page really slow, there was no measurable difference (even for a year's data) between the two approaches. So it's going to use ViewState to make the coding simpler. But I would have been happy even if the experiment had shown the ViewState approach was infeasible, because we'd have found out before a hundred pages were coded.

Joel Spolsky says pretty much any methodology makes good software in the hands of those who are good enough to develop methodologies, and they pretty much all can fail in the hands of those who just follow the rules and do what the methodology says. Big complex process (and as we grow, our process naturally gets more complex) runs the risk of becoming opaque to those who are asked to follow it. That's why we like to come back to some touchstones that explain why we do what we do. Like Fail Fast.

Failure can be a good thing. If it saves you from following a doomed path for a year, you're glad to have failed early rather than late. If you can learn from something that didn't work, it will have earned its keep. This morning I read a story by Steven Sinofsky (no longer an entry level programmer ) at Microsoft about the failure of a C++ application framework, essentially the first try at what became MFC. He concludes:

When I think back about the dismal failure of our first library ... and how we regrouped, learned lessons, and put those into play, I realized that without that first failure we never would have developed the success criteria that allowed us to build MFC.

I'm never afraid to fail and I am not ashamed when I do. The only shameful things would be to continue to waste time avoiding the final decision that it is a failure, or not to learn from it.

Kate

Yesterday I was at a client and we talked, among other things, about how their story would make a good one to deliver at a launch event. They have an existing project in C++, client-server with MFC etc. Using Visual Studio 2005, building on the beta, they have wrapped an ASP.NET UI around the server engine so that users who don't have the main product installed on their desktops can still look at and edit some of their data. The new features in ASP.NET 2.0 were so compelling that this client has decided to use the go-live licence and deploy on the beta. The availability of the beta to MSDN customers, and the updates with the CTP process, have helped this ISV get 6 months to a year ahead of those who wait for the launch.

Then today, I faxed back my contract for C++ Connections, which is happening the week of the launch. Although I have at least one confirmed (and two strong maybe) conference trips between now and Nov 7, I am very much thinking about that week and the excitement that will build as more and more people learn what's in the 2005 release.

Those of us who are in the loop, reading blogs from team members and executives, grabbing betas and CTPs, living out on the bleeding edge putting Vista on the laptop, can sometimes forget that a launch is still a really big deal to people who've been waiting for Microsoft to make a big “here's what we've got event”. While such events will always be important for getting the attention of those who weren't looking, these days you can see what they've got right now. If you're in the loop enough to read my blog, you can be just about as completely in the loop as I am. What a fun time to be a developer!

Kate

This is a cool little service, “Not Endorsed nor Authorized by Google in any way”, that lets readers show me where you are. Go on, zoom and pan and whatever till you find your location, then double-click to add your little face icon to the map.

Inspired, as I so often am, by Scott Hanselman.

Kate

I like having my editor and my build environment integrated with my source control, even if that source control is Source Safe (ugh.) I like being able to check in and out from Solution Explorer rather than a separate tool, and settings like “check out on edit” are handy too. But you know what I really want to be able to do? Right click a line of code and ask “who wrote this?” The answer would be the date, user id, and check-in comment from the last time a touch of that file affected that line of code. Anyone who has ever managed a team project has looked at a block of code, done a double-take, and then demanded of the air “who the %^^$# put that in there?” I want my editing environment to tell me that.

The information to do this is in the system. I can do it by hand by doing a Diff between versions until I find two versions where that line changed, then looking at the check-in details. But it's just the kind of boring job that's perfect for a computer.

I wonder if the source control in VSTS does this?

Kate

Did you know that Visual C++ 6, which is fast approaching its seventh birthday, will soon be an unsupported product? That's not exactly shocking; after all it was developed to let developers target Windows 95 or NT! Perhaps you were wondering when some other applications you use are going to reach end of life.... in that case, here are some handy links:

• http://support.microsoft.com/gp/lifesrvr for server products.... SQL Server 7 support ends this year, too. MTS has been out of support for years.
• http://support.microsoft.com/gp/lifedevtoolfam for developer tools... VB 6 will be in extended support for longer than VC++ 6. Go figure.
• http://support.microsoft.com/gp/lifeofficefam for the Office family.
• http://support.microsoft.com/gp/lifewin for versions of Windows. Windows 1.0 was still in mainstream support until 2001!

If there's something you don't feel like upgrading, you might want to know how long it will be supported for as part of your wait-or-upgrade-now decision.

Kate

I got an interesting email today with this subject line: Want to build the next generation of C++ Libraries?

Enclosed was the following, from Martyn Lovell:

Development Lead, Visual C++ Libraries

Want to set the standard for the next generation of C++ application? Ready to design code that will be used and critiqued by the whole developer community? Want to have a direct connection to customers whose problems you understand? Want to build a new generation of libraries for a new language running in modern environments? The Visual C++ Libraries team is the place for you. We own all the library code shipped for C++. We are building new libraries that drive developer productivity and power on the native and managed platforms. Next version we’ll have to understand how our customers are going to work with WinFX and move forward with their existing code. And we’ll have to bring our native and managed libraries up to date to work seamlessly with the technologies of the Longhorn Wave, WinFX and ISV applications like Office 12. We own the full set of C++ Libraries -- C Runtime Library, Standard C++ Library, MFC and ATL. In future releases we’ll also have to address some of the challenges of parallel programming, and migration of existing native applications to managed code. We’re looking for senior individual contributors ready to code, design and provide the next generation of code reuse though leadership at Microsoft. Degree in a relevant subject and five years of software engineering required.

We are anticipating expanding our team for our next version to allow us to build some new MFC and ATL features (such as integration with Avalon, and support for new UI styles). So we’re hoping to find one or two people with deep MFC experience to add to our team. You don’t have to be using MFC today, but we especially want to hear from you if you have written a good amount of MFC code in your past.

If you know Martyn's email address, go ahead and email him and mention you saw it on my blog. If you don't, email me (don't leave a comment) and I will forward it to him.

Kate

People regularly email me, or approach me at conferences, and ask me to “confirm” that Microsoft is trying to get rid of C++ in favour of C#. Since nothing could be further from the truth, I am not the person to get a confirmation from. But then again, I don't work for Microsoft, so maybe I'm deluded? That's why I like to find simple and unequivocal statements from people who do work for Microsoft, like this:

Visual Studio 2005 takes C++ development to a new level. For example, developers will get the same drag-and-drop experience creation of user interface as other languages, the same automatic statement completion and the same intuitive graphical debugger. Visual C++ 2005 developers will be able to build high performance 32-bit native code applications, use web services to interact with popular sites such as Amazon.com and Ebay, add professional quality 3D/2D graphics, video and sound using the DirectX SDK, all while generating robust and extremely fast code using our world-class C/C++ compiler.

C++ is here to stay for a long time and we are committed to providing the best tools for C++ development.

That's kind of hard to misinterpret. And when the Corporate Vice President of the Developer Division says it, you really need to believe it.