Beta 2 of VS 2008 is out. This is feature complete and a go live license is available.

Having used the CTP's, I'm still keen to spin up this release as soon as and looking forward to seeing the performance improvements around LINQ to SQL in particular. I'm supposed to be doing some DIY around our new house this weekend. I sense a domestic dispute coming...

From conversations I have realized that a few people are not aware that John Lam has announced the appearance of IronRuby.

Regular readers will know that I have been learning Ruby as my 'new language every year' so I am keen to take IronRuby out for a drive, so its obvious why I am interested, but the question is 'why should you be'.

Let's step to one side of Ruby for the moment and just note a couple of important policy issues that emerge with IronRuby. First IronRuby is going to be hosted on RubyForge, and will use the Microsoft Permissive License (which is IMO an 'open source' license). Microsoft will be accepting contributions to the libraries from the go, and to the language once the Dynamic Language Runtime (DLR) has stabilized. Actions speak loudly and this is a great response to the challenge that Martin Fowler laid down to Microsoft in his RubyMicrosoft post. In fact they seem to have pretty much gone the route that MF challenged them too, by opening it up to the community. Congratulations to Chad Fowler and others for stepping up to the plate and letting the MS boys play too. This looks like a fairly big win for the pro-open source camp in MS. This may resolve some of the issues around Ruby lacking a specification if Microsoft can engage the Ruby community.

The second point is that both the CLR and JVM are moving full steam ahead with ports of the Ruby language (the JVM version is JRuby). Moving Ruby to both of these platforms gives it the ability to run in the two sandboxes which dominate in corporate application development and interoperability with libraries on those platforms. That is a big boost in terms of reach, both in the number of shops that may now be willing to deploy Ruby and the libraries available for development. It also allows Ruby to work  easily with existing software assets on those platforms. The upshot of this is that I suspect that more corporates are likely to begin experimenting with adding Ruby to their tool mix over the next couple of years. Of course the availability of Ruby skill sets is still a  barrier to wider adoption, and the result of those experiments may not be adoption of Ruby in the tool mix; but it now becomes an easier option.

But whether you intend to play with Ruby or not, this is definitely a good day for MS developers.

Tim has a great summary of how TDD challenges assumptions and changes the way you think about good code. Great post, run over there and read it now. Tim's advice to throw anything out of your coding standard that does not agree with TDD is sound. I have been banging on about 'living in a more public world' for a while now, and it is something to get used to.

Rob Walling has a thoughtful blog, and interesting discussion in the comments on the issue of good developers being promoted away from what they are good at - delivering solutions - into higher level management positions. It does seem to be an issue in many professions that have a high technical content; those who are technically savvy become the prime candidates from promotion, without regard to whether they have the skills required for their new position.

The difficulty seems to be around the lack of a software career track that rewards experience and competence within the field beyond a certain level, instead of transferring into management.

Zi Makki is putting together a geek dinner on 24 July. The usual suspects from London .NET user group will be there, with others, so go on over to Zi's wiki and sign up.

My copy of London's free newspaper, the Metro tells me that the iPhone is a must have because it uses advanced EDGE technology. Sadly for the Metro's journalists EDGE,  is a step back from our current leading edge phone wireless service 3G, which most of the UK phone networks have invested huge amounts in by buying expensive licenses. My phone is 3G nad has been for a couple of years now, and I do not see any reason to take a step-back into yesteryear for Steve Jobs.

3G uses a different protocol to EDGE, so one reason for the delays in the iPhone being released here is that it seems unlikely many of the networks will want to support EDGE. HSDPA is advanced technology, but not EDGE.

The issue here is that the US lags Europe and Asia in mobile phone technology so Apple has pitched its device to the lowest common denominator - the US market. While I am sure PR departments can convince naive journalists at newspapers to print nonsense, whether the networks will want to do so, and risk confusing their existing customer base as to the differences between EDGE and 3G or simply wait until Apple can produce a 3G phone must be a different question. The problem for Apple is that Nokia and HTC are not likely to wait around to let them capitalize on any perceived technical advantages to their UI.

There is a myth floating around, for example in Frans Bourma's recent blog, that Agile methodologies tell you not to do documentation. It may be time to put the record straight.

Much of the confusion stems I suspect from the Agile manifesto which has the following value statement: "Working software over comprehensive documentation". I think a number of people have taken this to mean, agile does not do documentation. I think that is a misunderstanding of the intent of the agile manifesto. The manifesto is not a methodology, it is a statement of the common principles which underlie the differing agile methodologies, of what it should require for a methodology to call itself agile. Martin Fowler has useful backstory on this. So the agile manifesto is what XP, Crystal, DSDM et al. have in common, not an agile methodology in itself.

To understand the the admonition it must be remembered that the non-agile methodologies were often characterized as document-driven development because they required the production of innumerable documents before a line of code could be written. In many cases the process steps were being performed by software development teams simply because the methodology told them that they had to be performed, even when they provided little value. As a reaction many development teams abandoned methodologies altogether. Agile was an attempt to remove the production of documentation without purpose, and focus once again on the key artifact of the software process: the code. Unfortunately many people who have never practiced a full on waterfall process like SSADM, do not recognize what is being rejected, and thus assume the limited documentation of ad-hoc or in-house processes was being targeted too.

In addition many development shops mistakenly equated agile with no methodology, and where they had no methodology began to self-label as agile as a form of justification for their lack of process. The inevitable failures gave agile a bad name in many organizations who never realized that Agile was actually a set of methodologies, all of which required discipline and adherence to practices. As a result though, many people equated the poor documentation practices of these ad-hoc processes with agile.

A quick review of XP and Crystal Clear reveals that agile processes do recommend documentation.

Crystal considers development to be a series of co-operative games,  and the provision of documentation is intended to be enough to help the next win at the next game. The work products for Crystal include use cases, risk list, iteration plan, core domain models, and design notes to inform on choices. Crystal also defines the roles for these. Note however that there are no templates for these documents and descriptions are necessarily vague, but the objective is clear, just enough documentation for the next game. I always tend to characterize this to my team as: what would you want to know if you joined the team tomorrow.

As an example:


XP by contrast notes that documentation is not needed so much inside the team, as outside, and sees it as a costed story that needs to be delivered. The goal here is, I suspect, to reduce unnecessary documentation by forcing it to be evaluated alongside other feature sets. XP relies more heavily on programmer-to-programmer communication to distribute knowledge about the system than written documents, but mandates pair-programming to make this possible: because you share understanding with others through pairing, there are no 'dark areas', and less need for people to document what has happened. In addition the code and tests are seen as then primary repository of detail on how the software was implemented, for fear that documents always grow out-of-date and the natural inclination is to 'use the source Luke'. Beck states that apart from code and tests you should 'rely on social mechanisms to keep alive important history of the project'. Beck is unclear what these 'social mechanisms' are, but many projects I have worked on have used tools like wikis that create collaborative, constantly-edited, documents as repositories of history as one non-verbal, social mechanism, for recording project history. Also see this page for more on XP and documentation, but the summary is whatever the team needs or the customer wants.

As Crystal does not mandate pair-programming it needs to compensate by mandating a level of documentation to preserve project history. Crystal sees documentation as one of the work products and provides a list of what documents it would expect. Again though the documentation is purposeful - to ensure the next game is successful - and vague enough to encourage an only what you need for this project approach.

Personally, I am more aligned with the Crystal approach right now, as we do side-by-side programming, not pairing, so we need to preserve knowledge in writing. In addition, our structure requires handover of projects at times, so we need some documentation to effect that. I do have some warm feeling toward the idea of capturing history via wikis or even mailing lists so that we capture living information.

I have not used DSDM, though I worked for an organization that flirted with the idea in the '90's, but a review of the Wikipedia entry suggests that it has a significant number of artefacts produced throughout the development lifecycle.

The important thing to recognize here is that there agile covers a number of distinct methodologies, which while sharing common principles, differ in detail. You should  consider adopting a methodology (especially if you have no experience with agile methodologies and thus lack the experience to generate your own in-house alternative), and choose a model which matches your needs. Documentation requirements are just one part of that decision, but the desire to have documents need not be at odds with adopting an agile development methodology.

I've been made a C# MVP again as of July 2007. It is really great to know that Microsoft appreciate all the effort those of us who, speak, blog, run user groups, write books, answer questions in forums, and organize conferences make, and the value of the community that those efforts generate.

Rico has a post describing the improvements we will see in Beta2 to LINQ for SQL performance.

The headlines are that a compiled select gives us 93% of 'to the metal' performance, which is a excellent result considering what it is buying you. Tantalizingly updates and inserts outperform old-style ADO.NET code, and Rico promises to say more on why in a later post.

The key to the select performance improvement seems to be the use of compiled queries. Compiled queries might fit well with the repository pattern, as the repository encapsulates queries against the underlying collection that it abstracts. Of course, you can use specifications in addition to the repository. Folks who saw my presentation at DDD, know a little bit more about my suggestions there; more forthcoming in this blog soon. 

I'll review my posting on Persistent Ignorant approaches to using LINQ to SQL in  light of the performance benefits of using compiled queries, once I get my hands on Beta 2. (Having just moved house the big question remains will I get broadband hooked up in time for beta2).