ChrisCottee

I'm a former colleague of SteveFreeman, IvanMoore and SvenHowarth and OliBye (twice). I'm currently working with SteveFreeman.

I mostly do financial number crunching but my devotion to XP comes from experience of a particularly disastrous case of BigDesignUpFront? at Racal.

and to test cases from a rather undisciplined derivatives trading system? Indeed: I think six months of maintenance programming should be enough to convince anyone of the merits of unit tests.

Here's a nice link for you maths boy, or perhaps a squigler would like it more http://www.cecm.sfu.ca/projects/ISC/ISCmain.html -- OliBye

War Stories

1 EU project "demo something with AI for coastguards" After about 2 months we scoured the original proposals for the Europe wide project and discovered the bullet point that referred to us which is pretty much the quote above. We decided that risk assement and control would be interesting so we spent a lot of time discussing risk models, dynamic models of ship movement and writing interesting working papers: probably about six months. We then went on OOAD courses and got copies of rational rose: result was a lovely big design for a ship simulator which made interesting use of the strategy pattern to allow different dynamic models to be used etc. etc. At the same time I started looking at the problem of scheduling ships entering harbours and crossing the Channel (my first encounter with combinatorial optimisation and the phrase 'NP hard'). We then threw away the dynamic ship part of the project (we had just started to implement it). I knocked up a heuristic solution to the scheduling problem so that I'd have something to look at while I was trying to find a decent solution. We only talked to actual coastguards about 9 months in to a 12 month demo. Fortunately they were at least a bit interested in the problem we had decided to solve. Of course we actually demo'd the heuristic with a carefully chosen dataset. Nevertheless demo was a success and we all got paid.

Conclusions * learn to tell the difference between engineering and research * a suspicion of big design up front, made me receptive to the idea of YAGNI * business decisions are paramount, the swamp any effects you can have

2 Archiving system for tape recorders Main thing about this was that we had to drive tape recorders so that we could control which tapes were recorded over and log which tapes had been archived to. But we did n't have a tape recorder to drive until very close to the end of the project. I was nagged by the team leader to produce a dummy tape drive which logged how it had been driven. He also nagged mean to produce a very thorough spy for the comms between our server, client and tape recorders. He knew what he was on about and they proved very valuable. The test harness was a bit brittle and not fully automated but it did mean that when we plugged the real tape recorder in it just worked which impressed me a lot at the time. 3 Maintenace of interest rate derivatives system This system had grown over a period of years in which it was always just about to ship and most of the original team had left. There were no unit tests. Plus it was mostly C with a C++ front end. It was big and not possible to debug all at once and except at the very bottom, the code dependencies were all over the place. So fixing bugs or adding features was a very delicate business, there was a strong temptation not to change things in case something broke. You tended to add in extra code, not remove code even if you could not figure out which cases it applied to. When we adopted rigorous unit testing I found it completely liberating to be able to just refactor code, confident that if I had broken something I would find out immediately. There is nothing like maintenance programming to teach you the value of unit tests.

4 Financial toolkit This was an XP project to copy an analytical engine written in C into java. One of the notable things was that the unit tests were horribly brittle: the yield curve engine would churn out an array of about 50 doubles for each testcase and these had to be identical with the output of the existing engine. Now there were quite a lot of test cases so that's a lot of numbers to be pasted in. Then we start finding the bugs in the original engine (no unit tests of course). Hence repeated updating of the tests, which are end to end so tend to all break for every bug. The main difficulty was that the original algorithm was hard to break down into small steps that we could test individually. Also we did n't treat the test code with the same importance as the rest: big mistake you need to be able to change tests as easily as the rest of the code. So when we got to write a new bit of functionality (an inflation swap calculator) we wrote it test first which meant that the algorithm was chopped up into steps which were each testable in isolation so that the tests were more orthogonal and hence more robust. I was also introduced to the idea that you could do a big refactoring by doing lots of little refactorings and that you do not have to know where you are going: you just keep making the code a bit cleaner and eventually discover you have reduced the original structural problem down to nothing.

MathematicalProgrammingAndXP