Agile Scrum works great for building software projects. You have a deliverable product after each cycle where the development team focuses on delivering specific features without being sidetracked. But what happens if you apply this methodology to building airplanes?

The Columbia Enterprise Developers Guild meeting went well. I discovered that the demonstrations run too long for a Code Camp, so I will need to shorten it for next weekend's SoCal Code Camp. Justin James offered a great tip: put all the code into a prewritten application. This will definitely speed things up, but I think there are a couple of mollifiable drawbacks.

The first draw back is that some of the samples can't compile. This is either because I am demonstrating what can't be done (assign a List<string> to a List<object>). I can either put them in a project that I don't expect to compile and not compile the solution, or I can place them in code snippets.

The second draw back is I feel that it's easy to lose the audience when the code is already there. The temptation is to run through it with the expectation that the audience will understand it; after all, they're coders too. Of course, coders are human (sometimes). One way to handle that is to slow the pace down to a speed that's quicker than typing the code but still gets the point clearly across. Another way to handle it is to create a project for each little piece so that they're in digestible chunks. One reason prebuilt code is hard to understand at demonstration time is due to the irrelevant code surrounding where the focus should be.

The person in Florence who suggested I explain the difference between var and dynamic had a good point. I never considered understanding that an issue, but it makes sense if someone isn't familiar with C# 3.0. They assume var means variant, which is far from the truth.

I gave my new presentation, "The Future of Managed Code," tonight at the Pee Dee Area .NET User Group in Florence, SC. There was a pretty decent turn out for the presentation, and it turned out everyone was a C# developer. This meant I was able to gloss over the new features in VB10 and talk more about new features in C# 4.0. Even glossing over the VB10 material, the presentation went over an hour, so I think I will need to streamline some of it to fit the Code Camp schedules.

One problem I had was the speed of the VPC. I will have to figure out how to improve performance with it. I will add some more RAM so I can devote resources to it. Page suggested running the image off of a USB hard drive to prevent thrashing. I'll give both of those a shot to see what I can squeeze out of it.

One attendee recommended that I spend more time explaining what a dynamic is. Although I try to avoid slides, I think I will need to add some because a good visual can make all the difference here. In particular, the attendee was concerned that others may be confused by the difference between the var and dynamic keywords. It never occurred to me that this could be a problem.

I also need to fix the COM portion of the presentation. My excel application never popped up. I'll fix up the code and slap it into a snippet.

I'll be doing the same presentation tomorrow in Columbia, SC. Come out if you can make it!

The next versions of C# and VB will have improved parity between them. From the consultant perspective, this is important because one can't always choose which language to use. Although a seasoned C# developer can program in VB as well, it seems that gotchas appear and you have to refer to the documentation to figure out how do something that you wouldn't even need to think about in your primary language.

The goal of the Visual Studio Managed Languages team is to maintain the character of each language while introducing the same new features to both. In keeping with this spirit, they've introduced features from one language to the other while maintaining the target language's style and feel.

New C# Parity with VB

Late Binding - Although the new dynamic type isn't the same as late binding in VB.NET, it is similar in many respects.

Named and Optional Parameters - No longer will you need to chain tons of overloads. VB developers have mocked us C# developers a while about this. It also cuts down on the number of parameters you have to pass to COM method calls.

New VB Parity with C#

Auto-implemented properties - These are idential to C#'s auto-implemented properties in that the compiler will create a backing private member for you. However, VB does not get read-only or write-only auto-implemented properties.

Collection Initiliazers - No more have to call List.Add(...) over and over.

Array Literals - The compiler will now figure out what kind of array it is based on the types used to initialize it. 

Multiline Lambdas - The compiler accomplishes this by figuring out the widest type returned from the multiline function.

Implicit Line Continuation - C# has implicit line continuation for everything, since line termination is denoted by a semicolon or the ending of a block of code (curly braces). VB, in contrast, implicitly terminates lines and oftentime requires a line continuation character (underscore). The line continuation character is now eliminated for scenarioes where it makes sense that the line should continue. The rules for this are as follows: after an attribute, after a comma, after a dot, after a binary operator, after a LINQ query clause, after a parenthesis, after a curly brace, and after a <%= or %>.

New features added to both

Generic Variance - Remember the question about assigning a list of strings to a list of objects? Well, you still can't do that due to type safety. However, sometimes the generic only goes out. Conversely, sometimes it only goes in. You will soon be able to declare your generics that way, and it will allow things like an IEnumerable<string> to be assigned to IEnumerable<object>.

Compiling without Interop Assemblies - It used to be that a primary interop assembly (PIA) had to be distributed as another artifact with your application. This is terrible when you're using a small subset of the functionality: it could dramatically increase the size of your distributable. Worse still, it is possible to run into a dll hell situation with different versions of the pia. In .NET 4.0, you can have it compile the piece of the primary interop assembly used by your application into the executable, greatly reducing distributable size and versioning issues.

Most of these features are demonstrable in the Visual Studio 2010 CTP; with the exception of in and out generics. These features appear to be very useful and stable. Although CTPs are subject to change, I suspect these features will make it to the final release.

I opened my email this morning to discover that I received two awards. First of all, I was awarded 7th place in the Community Credit December 2008 contest. I wasn't able to log into Community Credit for months because my user name didn't appear to be working. However, last night I was determined to submit my points for the INETA Community Champion Program before the year ended, and that program links to the Community Credit program. I eventually figured out how to get my user name, then submitted everything I could remember from the past year. My prize? The Plug Mug!

More importantly, I was awarded MVP Visual C#! I am very honored to be recognized by the MVP program for my contributions to the development community over the past year. I hope to live up to the title and deliver even more for the community in 2009!

If you're not an MVP and haven't received "stupid prizes to smart people"; here's how you do it. Get involved. If you're reading this, you're likely already a software developer of some caliber. Join your local user group. If one doesn't exist, start one. Give presentations on something that interests you. Answer questions in forums. Blog about technology. Once you do this, you may even discover that the official awards given by organizations aren't the true awards. The true awards for being involved are the people you meet, the connections you make, and the personal growth you experience.