The VBUG UK 10^th Anniversary Conference is on next week.  Apparently there are still seats left – you can sign up here. Here are some reasons to attend:

While I'm at it, I'd like to point out that VBUG do a great job of running support meetings across the UK.  They also maintain a up-to-date list of user group events across the UK.

John Lam, together with Dominic Baier, shows how to implement a hex encoded SHA1 hash of a password plus a scope URI, as suggested by Keith Brown an improvement over WSE's default password handling for UserNameTokens.  Nice work.

Scott Hanselman has a 30% off voucher for MaxiVista an awesome 'virtual networked display adapter' that makes any computer that you can network to act as an extra monitor.  It's definitely worth downloading the trial at least.  Be warned though, you might find it so good that you may end up buying extra monitors (and here).  Once you've used multiple montors, it's hard to go back

When I first read about Scott using his Tablet PC as an extra monitor I thought it was something special with his tablet - turns out it was MaxiVista.  It can use any 'any type of network which supports the TCP/IP protocol (Ethernet, Wireless LAN. Firewire or USB network connection).'  The faster the connection, the better the performance.

I've been using it while I've been working on some hands-on-labs and demos.  I work with VPCs at full screen on my laptop and use MaxiVista to make my Tablet a second monitor that I use to display the word documents.  Christian Weyer uses the same trick when using Linux VPCs.

In a recent Opinari email (I can't find it on his website), David Chappell defends his belief reuse is one the fundamental benefits of Service-Oriented Architecture and that SOA will be more successful than previous approaches such as object-oriented or component-oriented development.  His rationale is that services operate at a higher level of reuse than binary classes, and they solve many of the human problems that prevent reuse, such as having to have one single view of business entities and forcing reuse through 'draconian' human policies.

Here's my summary of his three major arguments:

1. Service orientation will lead to better reuse of business-oriented software because it is about sharing application functionality at a higher level than binary classes:
   • Evidence for this comes from the fact that the most successful examples of business reuse comes from packaged applications such as SAP and PeopleSoft
   • Attempts to share business classes, such as San Francisco, haven't been successful.
2. Previous approaches to re-use have failed due to human reasons rather than technology:
   • It is hard to agree on a definition of a business entity, such as customer. 
   • Even if there is agreement about the 'one right view' then it is likely to change over time.
   • It is difficult to force developers to reuse software - given a choice (or allowed to get away with it) most developers will reinvent rather than re-use.  Where reuse has been achieved with previous technologies, it was mostly through 'coercive management structures'
3. Service-orientation overcomes some of the human issues involved with reuse because:
   • Services don't require a single definition of business entity, just conformance with a particular schema. A service-consuming application may have a different view of a business entity as long as it can map to the service's view of that business entity.
   • Services can better handle changes over time.  Service-boundaries are a better way of insulating consuming applications from changes to the internal implementation than base classes and binary inheritance as there is a cleaner separation of external interface from internal implementation.
   • Since services are more explicit with their boundaries, and often these boundaries are physical, it is harder for developers to find ways around them.  This is similar to Clemens' point that well designed services do not share databases.  David's argument is that these design decisions make it easier to enforce reuse.

I like his focus on the human problems that plague reuse.  I also agree that sharing schema is a better approach than sharing class (part of the four tenets of service-orientation), and that using interfaces rather than inheritance leads to more flexibility to cope with change over time (a well-known principle).   I find the argument that service-orientation will make re-use easier to enforce less persuasive, since this seems more to do with deployment than the design philosophy (a component-oriented application could also reuse components that encapsulated a private database).

Scott Guthrie has written an excellent post about the ASP.NET 2.0 development process and the steps to Beta 2 and a 'go live' license.  This is an interesting post on two levels.  First, I love learning about how Microsoft builds software (I love the game of shipping of software and finding out ways to improve it).  Second, I think ASP.NET is an incredible product and am excited about being able to 'use it anger' (as they say in the UK) soon.

Here are my notes on the key concepts from Scott's post.  It's interesting to compare the ASP.NET 2.0 process to Hervey's description of the WSE 2.0 process.

Zero Bug Bounce (ZBB).  A point where there are no open bugs for a particular milestone that are older than 48 hours.  The point is "to push teams to sustain a high rate of bug fixing over a period of time". The present goals is to avoid pushing any bugs past Beta 2, meaning that there will be a true zero bugs bounce occurring.  There is a lot more information on the ZBB concept: Eric Gunnerson provides a definition,  Ron from the Visual C++ team talks about the three types of bounce, Larry Osterman a long-term Microosftie talks about it in the context of Zero Defects and it's also part of the Microsoft Solutions Framework (MSF).

Regression Rates.  For the managed code parts of ASP.NET the 'regression rate is around 4% -- meaning approximately 1 in 20 fixes introduces a new bug in the product'

Bug Rates.  The test team opened 514 bugs last week, and the dev team closed 648 bugs.

Automated Testing.  The team has 102,000 test cases(!).  Automated FxCop runs are done over the product.  There are two levels of check in test suites.  There are base-level unit test coverage of the product prior to checkin that have a block level code coverage of around 64% and take several hours to run.  More extensive tests are run each night and take around 12 hours to run.

Checkin process.  All code is peer-reviewed (even for senior devs).

Security push.  After the ZBB returns to zero there is:

'an in-depth multi-week security analysis of the code in the product … The goal at the end is to feel confident that the product is solid and ready to be attacked by thousands of hackers out there while running on the Internet.'

Tell and Ask Mode
In Tell mode any team is allowed to fix whichever bug they wish, but they have to be able to stand up and justify their decision to the 'central division ship room'.  This helps slow the rate of checkins, which reduces the chance of regression issues, helping the quality of the code base increase.

Ask mode means that the central division ship room must give permission to make a change.  During this mode, the stress testing can continue.  The low rate of checkins makes it easier to identify the source of stress-test failures.

Go Live License. Scott mentions that Beta 2 will provide the first 'go live' license.  I can't wait for this to happen.

Another thing I think is admirable is that the ASP.NET 2.0 release seems pretty close to what Scott mentioned back in January as Chris Garty clarified off my notes from Scott's presentation.  Although they have had to cut and descope some features (See this article from Jonathan Goodyear, fellow RD) the team look like they've done pretty well sticking to schedule.

In an interview with Mary Joe Foley, Joel Spolsky says that Indigo will make building applications easier, but it won't lead to a whole new class of applications.

If you look at the different aspects [of Longhorn], like Indigo, I'm not really even interested. It's just a big communications architecture that makes it easier for programmers to build communications things. But there's no application you can't build right now because you don't have a good communications architecture. It might be harder (without it), but it's not going to enable you to build a whole new class of applications.

I think there is some truth in this statement.  As Steve Swartz has said, Indigo is a replacement of the infrastructure and an evolution of the programming model, through simplification and a unification.   As Clemens has demonstrated that you can use existing Microsoft technologies (ASMX, MSMQ, Enterprise Services, and Remoting) to do many interesting things today.  If you need to build a service oriented application it’s worth starting today and not holding off until Indigo arrives.  However, I think Joel underplays the benefits of making the programming model for service oriented applications simpler. 

The problem with building service oriented applications today is that it takes talented developers, like Clemens to do them.  As Don has mentioned, one of Indigo's goals is to make things so easy that he will have to join MS to survive. 

The applications that are developed on Indigo may not be ‘a whole new class of applications’ (though I think it’s highly likely that the killer apps of the future will be based on top of communication technologies), but the fact they are easier to develop them should lead to more of these types of applications being developed.  This is in the same way that VB enabled an increased number of COM applications that could have been built with C++.  It’s an interesting argument as to whether VB lead to ‘a whole new class of applications’ being developed.

There are several questions that I still have about the impact of Indigo:

• Where will the business imperative to build applications that communicate more come from?  Is it that there is a demand today but businesses aren’t developing the applications because of the technical cost? 
• Will the increased ease of development encourage businesses to build applications that they haven’t considered building today?
• Will the pool of distributed application developers increase, or will Indigo just be adopted by the developers who are already building distributed applications?
• Will the increased simplicity of Indigo mean that the architectural concepts behind service orientation will be more widely used?  For example, I’m puzzled as to why MSMQ doesn’t get more love – message queuing is an important architectural design and MSMQ works very well with a very simple programming API – but I don’t see it used as widely as I think it could be.

Thoughts? Comments?