How I nearly wet myself.

It's almost as if an external consultant was providing measured commentary on our team's management imposed attempt to go agile. We're using Mingle as a time sheet application, amongst other things, with the sweetener that the alternative is either Microsoft Project and/or a dedicated time sheet application. So far I've not yet found where I'm able to record getting up between 3am and 4am to check the ETL process which fails on account of a fragile FTP interface to Bloomberg. Still, it's early days and the good news is that we're hurtling towards automated builds.

Having tremendous fun playing find the missing ThoughtWorks.CruiseControl.MSBuild.dll.
At times it feels as if some twisted soul is curating the internet simply to thwart my efforts.

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.

It's been almost one week since we started doing this daily code Kata: Roy Osherove's TDD Kata 1 - String Calculator. Thirty minutes every day in October so far. Six days. Three hours. Writing the same functionality over and over. What happens is that, naturally, each time we get a little closer to the end (we've not yet completed it in thirty minutes) and we optimise by anticipating functional requirements and code to allow for simple changes ahead. We'll decide how much of this is cheating once we're actually done a few times within thirty minutes before moving onto the next Kata.

We're using just the one code snippet, TDDtestmethod, which generates a test method. We abandoned the calculator variable name, opting for c.Add instead.

Is there a prize for the longest [Test] case method name?

Calculator_ 
MultipleDelimeterVaryingLengthSpecifiedDelimitedMultipleStringDecimalValues_
ShouldReturnSummedValues()

Using underscores would only make matters worse. And when we looked at some of our tests recently we discovered that we were unit testing parts of the framework (guess we're still not sure about Entity Framework) and using unit tests for spikes too. The words "Gone Too Far" appeared suddenly.

Bouncing back and forth between System.Threading and XP, we spot something from Matt Wynne reminiscent of Thursday's Dojo:

Rod has just joined a new team who are using UNIX text editors to do their development in Perl. Rod is used to using the Eclipse IDE and has never really used these text editors before so he feels awkward and clumsy when he gets the keyboard. This is compounded by the fact that his team are using a mixture of editors and operating systems, with some people staunch EMACS users, others using VIM and yet more using Textmate on the Mac.
Personas for Debugging Pair Programming Session

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.

I've recruited an inexpensive live-in Python / C++ developer of Google Tor Project infamy from one of the Baltic states to pair program with me before he heads off to do a Masters degree elsewhere in London as the gumtree plea for someone to pair with has met with silent derision, I'm sure.

So far, I've shown him ReSharper; during the demonstration I find I don't know my own shortcut keys. Tools > Options > Keyboard suggests I have none setup. Why does this Visual Studio 2008 dialog show me only four items out of thousands at a time? Why does Visual Studio 2010 do the same? First the canonical Calculator.Add() example to make sure we're on the same page. Next, the Reload Countdown problem from the TDD problems list to make sure we can isolate on the process without being distracted by keywords, syntax or an unfamiliar API.

The naming convention for unit tests discussion briefly threatens to spiral beyond the seconds allocated. Found Bryan Cook's useful post on Unit Test Naming convention & Guidelines.

Pausing often to chat about names of variables and methods means noticeably slower progress than writing the code alone without being test-driven. As we do more of these it might be interesting to do some metrics. To tackle the problem with solution familiarity - by that I mean being able to go faster the second time round having already solved the problem once before whether using a test-driven approach or not - we'll alternate between having the first attempt being test-driven and test-later.

It feels a little odd to be doing this now, about forty-two Internet years after everyone else did. Thanks, however, to Benjamin Mitchell for getting us started. We're considering attending the London Python Dojo in two days. This looks like it's going to be interesting.

Notes

Ancient CodeBetter post with .NET Test-Driven Development Resources links.