Mort is the Microsoft “persona” often associated with VB, and for various reasons “Mort” has unfortunately become an insult.

But in reality, Mort is the business developer. You know, like the 3 million or so VB6 developers that have been programming for anywhere from 5-20 years and have a pretty good clue about how software is built. Mort is not a newbie or a hobbyist. Mort is a professional[1] business developer. In fact, the Mort persona represents the vast majority of developers. There are around 3-5 VB developers for every C++/C# developer out there. And an increasing number of C# developers are “Morts” as well - you don't stop being a Mort just because you change programming languages after all.

The highly productive majority of developers who build business systems day in and day out. These business developers typically build systems for 1 to 1000 users. Systems that are of critical importance to their business. Systems that are linked to the very lifeblood of the companies for which these people work.

Mort is the heart and soul of the Microsoft platform. Mort is the reason Microsoft development is pervasive in virtually all small to mid-sized companies, and why it is lurking in the shadows everywhere you look even in the Fortune 100. These are the business developers that won't say no, that won't give up and who refuse to spend weeks or months on over-thinking J2EE or COM+ architectures when they can have their software up and saving money in a few days.

These are the people who never left the "smart client" and so isn’t "coming back to it" in a revolution. Long-time business developers are the people who saw the web for the terminal-based monstrosity it is and never left the productivity of Windows itself. These are the true Microsoft loyalists.

They aren't the uber-geeks. They aren't in it for the love of technology nearly as much as for the love of helping their end users and their companies. They are pragmatic and focused on just getting stuff done and running and saving money.

It isn’t like quality doesn’t count. Quality is critical, but also relative to the task at hand. In most cases, adequate software that’s deployed in a couple months is infinitely superior to exquisitely designed and tested software that’s deployed in a couple years.

A very large number of these “Mort” business developers are still using VB6 and have yet to move to .NET. Whether these business developers stay in VB or move to C# doesn't really matter to me a whole lot. Speaking as a geek I think that what’s important is that they move to .NET, because it is a far superior platform than Windows. But is this actually important to the business developers themselves?

The fact is that the majority of business developers aren't going to change the way they work due to a new language or even a new platform. If .NET can't give them the high levels of productivity of VB6 they won't move. If Microsoft can't convince mainstream business developers that they can switch to .NET quickly, easily and in order to gain serious and pragmatic benefit they'll never move. Nor should they. If .NET doesn’t make their job easier what would be the point?

Personally I am convinced that Visual Studio 2005 (with its attendant new VB and C# languages and related tools) is the tipping point. Not from a geek perspective (though there’s cool stuff there too), but from a pragmatic get-it-done perspective.

The new data access features in ADO.NET and in Windows Forms are truly the best stuff Microsoft has ever done in this area. The levels of productivity for building business applications in Windows Forms are unmatched by any technology I’ve seen.

The new and updated Windows Forms controls and the streamlined nature of Windows development brings back memories of VB6. Yes, Windows Forms is still a new forms engine when compared to VB6, but finally we can honestly make the claim that it is easier and more powerful than its VB6 predecessor. We can sincerely show that a business application can be written faster and with less code in VB 2005 than in VB6.

Things like the new splitter control, the flow layout, the toolstrip (the toolstrip is my new favorite toy btw), the new datagridview and other controls are the keys to serious productivity. Couple them with the easy way you create template projects, forms and classes and you almost immediately have a highly consistent and productive development environment to match or exceed VB6.

At Tech Ed last week Microsoft announced that VS 2005 and SQL Server 2005 will be released around the week of Nov 8, 2005. If you are one of the very large number of business developers who’ve been holding off on .NET, I understand. But I strongly suggest you look at VS 2005 and VB 2005, because I’m betting you are going to love what you see!

[1] As in sports, a professional is someone who makes their living by doing something. In this context, a professional business developer is someone who makes their living by building business software

Several of the Tech Ed speakers (myself included) have donated an hour of our time to charity, and you can help!

Go to http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5587400881 and bid for your speaker of choice.

The idea is that you'll get an hour of valuable time you can use to get questions answered or problems solved, and the money will go to a good cause.

Virtual PC (and/or Visual Server) are the most wonderful things to happen in a long time - especially if you use any beta software or do any system configurations that might damage or corrupt a real system.

But getting these things to run fast, especially on a laptop, can be a serious challenge. Here's a checklist of things I've been doing recently to get decent performance.

1. Make sure to uninstall/reinstall VPC and SP1 after upgrading the host Windows XP to SP2
2. Make sure to install/reinstall the VPC add-in software on the guest OS after upgraded to VPC SP1
3. Put your vhd and vmc files on different physical hard drives (not just partition)
4. If possible, put your vhd files on a different physical hard drive (not just partition) from your host OS system drive
5. Before starting VPC, do the following on the host
   1. Stop SQL Server
   2. Stop IIS
   3. Stop any virus scanning software
   4. Stop Messenger or other IM software
   5. Close all apps
   6. Close or stop any other items in the system tray or via the Services manager - anything you can stop that doesn't crash the host is to your benefit
6. Grant your VPC the most memory you can afford. After doing step 3, I'm able to grant 640 meg to the VPC on a 1 gig host machine.
7. The more memory on the host machine the better. 2+ gigs of RAM rocks!
8. If you need to put the host in standby, close VPC entirely first. Not just VPC instances, but close the VPC console itself. There are bugs with VPC that cause display failure issues when the host comes out of standby
9. If your VPC mouse pointer ends up with a black box around it (in LiveMeeting or other projection software), go to your video settings under the Settings tab, Advanced button and turn hardware acceleration down one notch

I'm sure there are other tips and tweaks, but doing these helps a whole lot with VPC happiness!

It is clear to me that Service Oriented Architecture has gone about as far as it can go in a vacuum. And Service Oriented Programming continues to evolve somewhat randomly as vendors and/or standards bodies see fit (WSE, Indigo, etc).

So there needs to be more rigorous thought apply to Service Oriented Design. If we assume the SOA concepts of autonomous entities communicating via contract-defined messages over negotiated channels. And if we assume we’ll have programming tools that provide contractual synchronous and asynchronous communication vectors, then we can move ahead and work on thought models for designing services and systems composed of services.

Note that there are two very different aspects here. One is how to create a service, the other is now to build systems where services interact. The inside view and the outside view. And the rules and concepts are very different for each.

In that vein, here's a good/interesting article on SO design from Rich Turner at Microsoft. He’s taking the inside view and discussing some high-level design concepts for how you might build an autonomous service that still requires other services to function. He’s proposing a couple thought models that might be useful in design efforts – exactly the kind of dialog that is required to move SOD forward.

Personally I think that a number of the object-oriented design concepts behind CRC cards (class, responsibility, collaboration) apply equally well to services. In such a scheme, Rich’s relationships (constellation or fractal) would be listed as collaborators from a service.

I’m convinced that at least the first side of a CRC card, where the class (now service), responsibility and list of collaborators (other services) are a good design tool for services. Some of the other sides (like the list of behaviors) aren’t so useful, since a service is an atomic procedure and thus by definition has exactly one behavior. Still, applying those parts of CRC that do work is very helpful.

Over the past few weeks I've given a number of presentations on service-oriented design and how it relates to both OO and n-tier models. One constant theme has been my recommendation that service methods use a request/response or just request method signature:

   response = f(request)

or

   f(request)

"request" and "response" are both messages, defined by a type or schema (with a little "s", not necessarily XSD).

The actual procedure, f, is then implemented as a Message Router, routing each call to an appropriate handler method depending on the specific type of the request message.

In concept this is an ideal model, as it helps address numerous issues around decoupling the client and service, and around versioning of a service over time. I discussed many of these issues in my article on SOA Covenants.

Of course the devil is in the details, or in this case the implementation. Today's web service technologies don't make it particularly easy to attach multiple schemas to a given parameter - which we must do to the "request" parameter in order to allow our single endpoint to accept multiple request messages.

One answer is to manually create the XSD and/or WSDL. Personally I find that answer impractical. Angle-brackets weren't meant for human creation or consumption, and programmers shouldn't have to see (much less type) things like XSD or WSDL.

Fortunately there's another answer. In this blog entry, Microsoft technology expert Bill Wagner shows how to implement "method overloading" in asmx using C# to do the heavy lifting.

While the outcome isn't totally seamless or perfect, it is pretty darn good. In my mind Bill's answer is a decent compromise between getting the functionality we need, and avoiding the manual creation of cryptic WSDL artifacts.

The end result is that it is totally possible to construct flexible, maintainable and broadly useful web services using VB.NET or C#. Web services that follow a purely message-based approach, implement a message router on the server and thus provide a good story for both versioning and multiple message format stories.

Indigo, btw, offers a similar solution to what Bill talks about. In the Indigo situation however, it appears that we’ll have more fine-grained control over the generation of the public schema through the use of the DataContract idea, combined with inheritance in our VB or C# code.