These are my notes for Spa2008 conference, which took place from 16/03/2008 to 19/03/2008 at Robinson Centre, St. Neots, Bedfordshire. I was attracted to this conference because there are no comparable events in France, or at least none that I am aware of: A place to meet other people from diverse horizons working on software through various roles (project managers, coaches, developers, testers,  architects, even a few academics). It was perfectly organized in a very pleasant venue: nice food, clean rooms, plenty of space, green surroundings.  

Overall the conference was interesting, but not as much as I would have expected it to be. I was delighted to encounter a small group of people interested in functional programming languages and notable Haskell. There seems to be a trend emerging there: Lot of people think that such languages could become The Next Big Thing, but they don't know how to help this happen, and most are puzzled by the shift of thought they require, even more so with such a complex type system as Haskell.

But I did not learn much new things, it was more a reminder of important things to keep an eye on, a broad overview of the field with some hands-on exercises to do. I had a hard time making contacts, although I had some interesting and/or entertaining conversations. My english is still a bit rough to make it easy jump in and out of conversations, and most of the people here were british, with an interest mostly on british affairs.

I may come back next year but only if I manage to present some session, as this is really the only way to attract some attention and make new contacts.  

20080318: Developing for social network sites

Some introduction to developing software for facebook et al.

20080318: Language Matters

A talk by L.Peter Deutsch, initial developer of Ghostscript

Interesting talk about nearly 50 years of Software development experience. Focuses on language issues

  1. every programming project is some sort of language creation, development of an idiom or dialect dedicated to some problem.  
  2. some desirable properties: referential transparency, compositionnality, expressive power and abstraction
  3. DRY: only say it once

20080317: Metrics BOF

BOF about metrics, their definitions, their usage. Not many participants: Anthony, a manager from BT, a professor from Cambridge.

Main goal of BT: promote reuse at all levels (components, projects, assets, services); How to measure reusability of some asset (without measuring its effective reuse ? and what is reuse ?): everything as a service. We can measure  coupling/cohesion at code level (ie. using classic OO metrics), then aggregate those figures across projects.

It is important to measure business value, that all participants in a project keep in mind the overall goal: maximising this value. By letting metrics be public, there is social pressure.

Some conclusion:

  1. we need to measure business value, something that is agreed upon and meaningful
  2. this is dependent on organization/customer objectives
  3. we need some up-front testing/acceptance system to ensure getting things done right as soon as possible
  4. the most important aspects of a project's metrics are its dynamics

20080317: Real Options

Prolongation of an InfoQ article. The idea comes from finance but no calculations can be done (ie. the Black-Scholes model make assumptions that are simply not true in the real world). Should be termed simply options but the finance guys hijacked the term, so enters real options

Fun session with lot of small games to help us:

20080317: Panel: Is software practice advancing ?

Basic conclusion: not that much.

Seems to me that panelists were a bit pessimistic, this sounds like a bunch of old-timers recollecting their memories of when they were young. Nothing new under the sun for the last 15 years seems to be the motto.  

20080317: Code Debt

Really fun and enlightnening session, very crowded too !

We first had an exercise, with the audience split in two parts on 2 different code base. The code was javascript computing camel-case transformations: to, from, with/out underscores, capitalized... The exercise was tweaked such that team A had a very clean and concise code base (I was in Team A), and Team B a haphazard collection of functions with lot of debt

Presenters identified 5 levels of code-debt relationship within a team:

  1. Nothing: code debt is not even known as a concept, coding is done in hacking mode
  2. Aware: code debt is known and is expected to be avoided  
  3. Critical: ??
  4. Addressing: team start to address code-debt issue, eg. through peer reviews  
  5. Managing: code-debt is managed through a code-improvement program
  6. ???: coding debt-free

Then there was a presentation of a practical approach to understanding and managing code debt:

  1. Recognizing debt: we had an exercise to criticise a code base (eg. jetty's buffer management) and identify common patterns. Code debt was categorized as: Simplicity, Conceptual integrity, Behavioural integrity, Comprehensibility
  2. Forensic accounting: identifying where debts come from: haste, delivery time pressure, developer's sloppiness, team churn and high tunrnover rate.... Those factors should be addressed: giving more time (or reducing scope), train developers, use tools, enforce conventions...
  3. Balancing the books: all the techniques that eliminate debt, refactoring mercilessly. This implies knowledge of the language/libraries/tools involved.  
  4. Auditing: retrospective and feedback over your debt-repayment actions.  

The team should make its own rules to prevent debt, common debt patterns should be identified and prevented.

Debts is a function of time and the longevity of your code. This is always underestimated.  

20080316: Functional Finance tutorial

The first day tutorial on programming financial software with OCaml. Good but a bit quick presentation of the problem: computing yield curves and loss distribution (??) for some assets' portfolio. As far as I can tell, the idea is to evaluate risks associated with each asset taking into account their correlation with other assets. There are two methods for doing this:

  1. use a Monte-carlo algorithm to generate an approximation of the loss distribution,
  2. use a semi-analytical solution to the problem for more direct computation.

The tutorial was about rewriting a C++ function named inverse that computes an inverse cumulative normal distribution (that is the probability that <code>P[X >= Z]</code> given that Z is random variable following normal distribution). The algorithm uses several  polynomials with constant coefficients.

I had lots of technical problems getting started:

Here is the result of my effort, together with Vanni:

(* see http://home.online.no/~pjacklam/notes/invnorm *)
open List;;


exception OutOfBounds of string;;


let  a = [-3.969683028665376e+01; 
           2.209460984245205e+02; 
          -2.759285104469687e+02; 
           1.383577518672690e+02; 
          -3.066479806614716e+01;
           2.506628277459239e+00 ]


let b = [-5.447609879822406e+01;
          1.615858368580409e+02;
         -1.556989798598866e+02;
          6.680131188771972e+01;
         -1.328068155288572e+01; 
	  1.0 ]


let c = [-7.784894002430293e-03;
         -3.223964580411365e-01;
         -2.400758277161838e+00;
         -2.549732539343734e+00;
          4.374664141464968e+00;
          2.938163982698783e+00 ]


let d = [7.784695709041462e-03;
         3.224671290700398e-01;
         2.445134137142996e+00;
         3.754408661907416e+00;
         1.0 ]


let low_prob = 0.02425
let high_prob = 1.0 -. low_prob


let inverse p =
  let rec cqacc acc c q = match c with 
      []      -> acc
    | x :: xs -> cqacc ((acc *. q) +. x) xs q in
    match p with
	0.0 -> 0.0
      | 1.0  -> 1.0
      | p when p < 0.0 || p > 1.0 -> 0.0
      | p when p < low_prob  ->
	  let q = sqrt (-2.0 *. (log p))  in
	    (cqacc 0.0 c q) /.
	      ((cqacc 0.0 d q))
      | p when p > high_prob -> 
	  let q = sqrt (-2.0 *. (log 1.0 -. p))  in
	    (cqacc 0.0 c q) /.
	      ((cqacc 0.0 d q))	      
      | _ ->
	  let q = p -. 0.5 in
	  let r = q *. p in
	    (cqacc 0.0 a r) *. q /.
	      (cqacc 0.0 b r)


let random = fun _ ->
	inverse (Random.float 1.0)




There is still lot of place for improvement to make it more compact. Here is the solution given by the presenters: previous

(* see http://home.online.no/~pjacklam/notes/invnorm *)
open List;;


exception OutOfBounds of string;;


let  a = [-3.969683028665376e+01; 
           2.209460984245205e+02; 
          -2.759285104469687e+02; 
           1.383577518672690e+02; 
          -3.066479806614716e+01;
           2.506628277459239e+00 ]
let b = [-5.447609879822406e+01;
          1.615858368580409e+02;
         -1.556989798598866e+02;
          6.680131188771972e+01;
         -1.328068155288572e+01; 
	  1.0 ]
let c = [-7.784894002430293e-03;
         -3.223964580411365e-01;
         -2.400758277161838e+00;
         -2.549732539343734e+00;
          4.374664141464968e+00;
          2.938163982698783e+00 ]
let d = [7.784695709041462e-03;
         3.224671290700398e-01;
         2.445134137142996e+00;
         3.754408661907416e+00;
         1.0 ]
let low_prob = 0.02425
let high_prob = 1.0 -. low_prob


let inverse = fun probability ->
  let accumulate = fun coeffs multiplier ->  
    fold_left (fun last_val this_val -> (last_val *. multiplier) +. this_val) 0.0 coeffs in
  let outer_approx = fun adjusted_prob -> 
    let multiplier = sqrt (-2.0 *. log(adjusted_prob)) in
	  (accumulate c multiplier) /. (accumulate d multiplier)
  in 
    match probability with
      p when p <= 0.0 || 1.0 <= p ->
        raise (OutOfBounds (Format.sprintf "Probability %f" probability))
   | p when (0.0 < p) && (p < low_prob) -> outer_approx probability
   | p when (high_prob < p) && (p < 1.0) -> -. (outer_approx (1.0 -. probability))
   | _ ->  let q = probability -. 0.5 in
	         let r = q *. q in
			((accumulate a r) *. q) /. (accumulate b r)
	 ;;


let random = fun _ ->
	inverse (Random.float 1.0)


I regret that the session was too short to have an in-depth (or even broad) overview of the benefits and tradeoffs involved in choosing a functional language such as OCaml for implementing financial software.