[Haskell-cafe] consulting and contracting

[Anton van Straaten]

Paul Johnson wrote:
> On 15/12/09 21:19, Anton van Straaten wrote:
>>
>> Without that advocacy, this client would have used Java by default.  
>> As it was, the first of those two systems was developed in parallel 
>> with a Java version, and we used the two versions to verify each 
>> other's results.  For the second system, a Java version wasn't deemed 
>> necessary, partly because the comparison succeeded in making Haskell's 
>> advantages sufficiently clear.
>>
> 
> Can you give us some more details on this dual-language project?  I'm 
> trying to collect objective evidence of the relative advantages of 
> Haskell and Java (or any other languages) and this kind of comparison is 
> gold dust.  Very few companies are prepared to develop the same system 
> twice.
> 
> SLOC counts are good objective evidence (preferably from a standard SLOC 
> counter such as http://www.dwheeler.com/sloccount/).   Days of effort in 
> development and defect counts are also powerful (although more subject 
> to random noise: give several developers the same job and developer 
> effort seems to vary even more than SLOC).  Also any specific anecdotes 
> about changed requirements, defects discovered by QuickCheck can also be 
> useful.  They are not objective evidence, but people listen to stories 
> more readily than statistics.

This project wasn't a controlled experiment, so even an SLOC comparison 
would require some effort, since there were various differences between 
the two versions.  E.g., the Java version generated PDF output for 
investor consumption, whereas the Haskell version provided a web 
interface for internal use.

One of the initial goals of the Haskell version was as a way to provide 
a cross-check for the Java version with relatively low effort.  Because 
of that, the Haskell version initially had no user interface, other than 
GHCi, and running a test involved writing code to set up the necessary 
input.  As a result, the development of the two versions had quite 
different trajectories.

The Haskell version did uncover a number of bugs in the Java version, 
and there were at least a couple of cases where the reverse occurred, as 
well as a few cases in which a discrepancy revealed some issue with the 
specification.  I'd have to trawl through old records to get actual 
counts.  My memory is that QuickCheck only discovered one real bug, in 
some custom date handling code.  However, I didn't use QuickCheck all 
that much, since the emphasis was on the cross-check with the Java version.

Working on the project, it was fairly easy to see the advantages Haskell 
had, but documenting that objectively requires more effort.  Agility was 
certainly one of the advantages, since the specification of the model 
was being developed along with the code, partly in response to the 
results produced by the code.

Some detailed comparison of source code might reveal some interesting 
differences, but I don't have access to the Java code at present 
(although getting access is not out of the question.)

> Of course if you can reveal the client's name that would also be very 
> useful, for the same reason.  But I understand that may not be possible.

The name isn't one that people would recognize.  They currently have 
active deals under development, and assuming some of those complete in 
2010, I should be able to talk more about specifics.

Anton