Seduced to Compliance by the Process's Dark Side

Bloged on PL's suggestion ...

Working in a Agile fashion can be hard. It means collaboration, passive compliance is not enough. Using eXtreme Programing processes is even harder. XP is a set of high discipline processes. But I've often noticed that the jargon of both Agile principles and XP processes are just too easy to misinterpreted. This has lead to the birth of an Agile and XP dark side, an interpretation that absolves developers of all responsibility, encourages passive compliance, and gives the customer god like powers. It moves responsibilities to the customer.

The XP Dark Side seems to me like planning for failure in a way that the developers cannot be blamed. It is the customer who will be left holding the baby. Real seductive if you want to code without responsibility.

The most recent XP Dark Side smell I have come across is the:

'A story is what the customer says it is.'

All hail the customer :-)

The customer is seen as an all powerful, all knowing, boss figure. The developer a passive compliant servant. Sometimes this comes from the customer as:

'I'm the customer, I can do anything I want.'

Command and control? Certainly not agile.

A collaborative team (which includes the customer) should never move forward without the customer's full agreement, so at the end of the day the story will always be what the customer, and the team, say it is. The customer is a vital leader and owner here, but he/she is not all knowing. The team has a responsibility to work with the customer. Collaboration (Agile) is a choice, but if taken, it requires everybody to contribute to help.

I think that an Agile developer's responsibility includes investigating the cause of defects to validate the design and remove the source of future defects. Code health is the team's responsibility. To delegate this to the customer leaves a conflict of responsibility which results in the 'oh that happened because you did not let us ...'. To delay the investigation distorts velocity and the work must be done and leaving it only increases the cost.

So customers ... beware of the dark side :-)

NCover Scalability

We seem to have hit a glass ceiling with NCover on our build process. We run NCover on all builds to ensure that coverage does not fall (thanks to NCoverCop). In the last couple of days we have started to get out of memory exceptions. It seems that the process of generating a coverage report just takes too much memory.

The project is significant but not large (yet) so this was a surprise. The solution seems to be to break up the coverage test into multiple build tasks.

Is Domain Entity Migration The Real Need?

'Data Migration' has always been a real 'challenge' in each project I've been involved in. Sometimes it is a seen as migrating application file format, other times database schema. I wonder if the perception does not match the need and hence ends up more complicated than necessary.

Where the file / database is used to persist an application's state or configuration, and not raw data to be processed, I'm thinking that they are presenters (aka UI forms) that happen to provide persistence. This perspective moves the focus to being able to migrate application objects, the file format is an 'end to means' rather than the objective.

The 'need' is to be able to restore an application's state. Maintaining some presentation of the that sate (ala file format) is one of multiple solutions and not the objective/need. These conversations so often come down to what we think is possible rather than what is needed.

I'm hoping to use this approach with NXMLSerialiser (to be known as NSerializer) so that migration can be supported independent of file format such as binary or XML. It is the objects that matter.

A snapshot of my current thinking:

    public class VersionMigrationBuilder : IVersionMigrationBuilder
    {
        public void Build(IVersionMigrators migrators)
        {
            migrators.PriorToVersion(1, 2, 3).UseMigrator(new V010203Migrator());
            migrators.PriorToVersion(1, 2, 2).UseMigrator(new V010202Migrator());
            migrators.PriorToVersion(1, 2, 1).UseMigrator(new V010201Migrator());
            migrators.PriorToVersion(1, 2, 0).NotSupported();
        }
    }

    public class V010201Migrator : IMigrator
    {
        public void Build(IVersionMigrator versionMigrator)
        {
            versionMigrator.ForType("TypeNameA")
                .RenameTo("TypeNameA_new")
                .DiscardField("noLongerLovedField")
                .RenameField("oldFieldName").To("newFieldName")
                .SetNewField("newFieldName").To(42);
        }
    }

I'm keeping notes here.

Iffy Density - A Useful Metric?

Any mention of code metrics is on slipery ground. Metrics are good, given a problem, and are best only used until the problem is solved...


I wonder if an 'Iffy Density' (my invention until I'm told otheriwse) is a useful metric to indicate code health and probable defect density.

Iffy Density is a measure of the number of 'if' / 'case' statements within a method or class. Will these add to code's TLA infestion with MID and CID :-)?

Using Subversion Revision as the AssemblyVersion - Revisited

I've been using MSBuild tasks for a while to automate the generation of an AssemblyInfo.cs file with an AssemblyVersion that matches the current Subversion revision (commit number). See my prior post here. But, I've had mixed success with that approach and this posting is about using the Tortoise SubWCRev.exe utility that I hope will be more appropriate to open source projects.

The Need

• Automate the file and assembly version numbers to use the Subversion revision number for the revion number in '...'.
• Make the project configuration visible in the Visual Studio 2008 UI.
• Suitable for debugging by typical developers using the VS2008 UI.
• Project compilation without third party application installation.

The Problem

The MSBuild community task approach works but its configuration is obfuscated from the typical software developer user. It requires all users to have the MSBuild community tasks installed on the developer's (user) PC. That alone is not the 'obfuscation', thing is that if a user tries to build the project on a PC that does not have the MSBuild communicaty tasks intalled they are given an error that cannot be fixed withing the Visual Studio 2005/2008 UI that they are using. This is the critical 'usability' issue that I have found.

It has not been such a problem for commercial use as a software devs are resolved early and only once on each developer box and probably documented for future developement or maintenance.

But I have found it to be a big inhibitor for open source software users. The code cannot just be download and compiled without either reading all the documentation to find such details (a deoderant ... it ought to be self evident or, better still ... just work). It means that if you have many users you will incur a significant support cost or the inhitor will reduce user product acceptance. In other words ... ungood.

The Solution

After much googling I came across Bruce Boughton's blog showing how to use the TortoiseSVN SubWCRev.exe utility in a pre-build event. His solution did require a little pocking around in the Visual Studio project file and also required TortoiseSVN to be installed on the PC. I've adapted it a bit here is my solution:

1. Add the existing AssemblyInfo.cs file to Subversion's ignore list. This file will be replaced by the auto generated file later.
2. Copy your existing AssemblyInfo.cs file to a file named AssemblyInfo_temp.cs. This will become the source file used by the auto generator. Move this new file into the Properties folder by drag and drop in VS Solution Explorer pane.
   
3. In the new AssemblyInfo_temp.cs file add required SubWCRev.exe keywords. We want to set the version revision so change your [assembly : AssemblyVersion("1.0.0.0")] to [assembly : AssemblyVersion("1.0.0.$WCREV$")]. If you want the FileVersion to be the same, delete the FileVersion entry.
   
4. Copy the TortoiseSVN SubWCRev.exe file into your source tree. I keep a Lib folder in the root (trunk) of all my project source folders. In this case I copy the file to Lib\TortoiseSVN\SubWCRev.exe to make it clear it is a TortoiseSVN file. This way anybody can download the project and compile without the need to install TortoiseSVN (although anybody using Subversion should anyway).
5. Now add as a project pre-build event: $(SolutionDir)..\Lib\TortoiseSVN\subwcrev.exe $(ProjectDir). $(ProjectDir)Properties\AssemblyInfo.cs.tmpl $(ProjectDir)Properties\AssemblyInfo.cs.
   

Done. This solution does require copying a TortoiseSVN file into your source tree. TortoiseSVN is an open source project, check its license to be sure you can use it. Otherwise install TortoiseSVN and reference the installed file.