During our three day Agile Training course with too many examples contrived to maintain audience engagement through cute caveman cartoons and engineering attempts familiar to all (house-building), one colleague questioned how suitable agile might be in model driven development.

The Agile view was presented in one instance as making use of Zeno's Paradox in reverse. The paradox says, essentially, that motion is illusory because to travel any distance there is a point half the way between start and finish (let's call this half-way) and there is also a point half the way between start and half-way (let's call this a quarter of the way) and so on. Because there are an infinite number of these half-way points it's impossible ever to get anywhere. This being the case the Agile take is that perhaps we're able to make better progress by considering how to only get half-way as opposed to considering in too much detail the end-game (or the whole journey).

If Agile's Raison (Scrum in this example) primarily is to produce some complete functionality periodically (frequently) in tight iterations then the question in the case of model development is "how much value does half an algorithm provide, if any?" If it's not possible to go to market with half a model then shooting for half-way appears only to help as a strategy for maintaining motion rather than for more frequent delivery.

Stated another way: Because the Quant team who are building complex mathematical models are unsure what the finished product will look like they almost have no choice but to work iteratively. The question is then whether their iterations include the development team and so far it looks as if they've not done so sufficiently that Agile's value here probably isn't more frequent delivery of complete vertical slices but helping to ensure that the direction traveled is more likely to be correct by facilitating conversation.

If more frequent contact between the Quant and Development team then mean fewer wasted cycles and fewer trips down blind alleys which might have resulted from more isolated efforts then it's another tick in the Adds Value column - this scenario leverages the Wisdom of Crowds. However, design by committee might just as easily be a problem instead. We'll see.

Returning to the initial question of how well suited the Agile Methodology might be for Model Development, Scott Ambler provides one possible answer: Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development.

Meanwhile I'll be discovering how well Continuous Integration works on a development team of one and whether the overhead can be justified.

We've been on a mission since last week to get exposure to the test-driven as opposed to the test-sometime so tonight we find ourselves at the offices of Fry-IT in Southwark, London watching at least two Python gurus doing Code Dojo. It's reassuring to see recognised developers halted by unfamiliar editors and settings on an operating system few here have used regularly, no matter how pretty Mac OS might be.

We witnessed a Randori Kata:

A challenge is set and solved by pair programming (driver and co-pilot). Each pair has a small amount of time to advance the solution using TDD. When the time is up the driver goes back to the audience, the co-pilot becomes driver and one of the audience step up to be co-pilot.

Folks took it in turn driving/co-politing to create a social network graph using Graphviz based on Twitter friend/follower data. For someone who'd seen maybe five lines of Python (and ignored four of them) prior to this evening, this was a nice introduction to the language as things progressed at a nice, gentle pace. Whilst getting up to speed one helpful guy pointed out his Interactive Python Tutorial written in Silverlight. Nice.

It didn't take too long to see out why the language has become so popular. Take Fibonacci:

def fibonacci():
    a, b = 0, 1
    while True:
        yield a
        a, b = b, a + b

Compared to the C# 3.0 implementation it's utterly readable

Func fib = null;
fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;

The Python version fares even better than the C# 2.0 version

static int a = 0;
static int b = 1;

public static int DoFib(int num)
{
    int temp_value;
    if (num < 2)
    {
        a = 0;
        b = 1;
    }
    else
    {
        DoFib(num - 1);
        temp_value = b;
        b = a + b;
        a = temp_value;
    }
    
    return a;
}

Pretty good for a first code dojo; I took along a proper Python Developer to decipher some of the odd-looking, intellisense-free text appearing onto the projected screen. The next Python Coding Dojo is on in October and by then we may even have written something in Python. Baby Steps.

Caught .NET Rocks show #445 with Kenn Scribner on REST. A useful discussion about REST, SOAP, the evolution of 'web services' technology and where WCF best fits in. Listen here.

Notes:

.NET Rocks talk transcript