cumulativehypotheses

[There are updates, and also useful discussion in the comments]

Join the Slack team for this competition where the baseline requirement is on the backlog. Get an email address to me somehow and I will invite you. PLEASE NOTE that the use of Slack does not imply any sort of real-time interactive collaboration between participants, or between participants and myself. Slack enables but does not require “chat”. If you choose to participate you will be added to the Slack team and, I believe, be able to see what conversations have gone before. 

Let’s say that you think it’s really important that people who work as programmers write their code in a certain way.

Whether this is for aesthetic reasons, or economic ones, or…actually the reason why you think this is not important. Only that you do. And, for my purposes, how you think they should isn’t important either. Maybe you think that they should only write assembler using pen and paper, maybe you think they should always use the very latest IDE to write dynamically typed OO code using TDD, maybe you think they should write using only pure functions and immutable data, maybe you think they should have rigorous proofs of correctness of every line of code, maybe…no, I don’t care. Only that you do.

Here’s the thing: advocates of one programming language, paradigm, toolset, what-have-you, always have really good explanations for why their way ought to be the best—for whatever figure of merit they say they care about—but we don’t really know. This should really be a topic for academic research but unfortunately no one is prepared to pay for the sort of study that would really settle the question, which would be astonishingly expensive. For practical reasons, what studies there are tend to be based on small cohorts of students who work on toy problems (code katas and such like), for a short time, once, having received a few lectures on whatever the techniques in question are. There is no reason to think that the results of such experiments should carry over particularly well to the work of seasoned practitioners.

But, maybe we can take advantage of the enthusiasm of advocates to do a semi-controlled, informal study using seasoned practitioners.

This is an idea that I’ve been kicking around on twitter with John De Goes. He likes a certain kind of functional programming. I don’t, much. I like a certain kind of OO programming and John doesn’t, much. What if, we wondered, some people who really knew what they were doing were to use their preferred approach to address a realistic—but small, we are talking about volunteers—problem under something like industrial conditions? What might we, they and the programming world at large learn about what the various programming paradigms do and don’t lead to?

“Industrial conditions” here means things like: that the scope of the problem grows and changes over time, that you—therefore—don’t know and can’t even in principle find out what the entire scope is, that the very goal of the exercises changes under you. If such volunteer expert practitioners were to work on such a system then we could look at what they have to do as those things evolve and develop and we could try to get a handle on how different programming paradigms—in the hands of seasoned practitioners—perform against a figure of merit of great interest in industry: how hard is it to adapt the code to new or changing requirements.

And this would be a back-office-y, line-of-business-y problem, because that’s so many programmers’ bread and butter.

I have such a problem in hand.

The Exercise

There’s a business domain that I know reasonably well: the scheduling of advertising copy into commercial breaks between TV programs on a linear-broadcast station. You can, of course, buy COTS software to manage this problem. Such products are vast in scope and mind-boggling in expense. But the central problem is—to begin with—simple. I think that this is a good proxy for a broad class of business problems.

Data stores can be file based, or use an integrated in-memory database of some sort, but no separate database products, please. Processing can be mostly batch, with a very minimal interactive command-line interface if required.

Product Owner

Here’s how it will work: I will be the Product Owner.

There will be is a Slack channel where stories will be published and volunteers will ask me questions from time to time about stories and I will answer, from time to time—so everyone can see both questions and answers, asynchronously. I do not expect to hold any synchronous conversations about this on Slack. In fact, to provide an equitable environment for all participants, I will not hold any synchronous conversations. Such answers will be—for the purposes of the exercise—normative.

There will be a backlog of stories, quite a long one, recorded as a series of additions to a text file in a private github repo. So that I can’t prejudice the exercise stories will be written far in advance and published from time to time along with the hash of the checkin which added them to the backlog. At the close of the exercise the repo will be made public and everyone will be able to see that the backlog wasn’t manipulated along the way to favour or disfavour any one implementation.

I won’t intensively test anyone’s code, but I will review the means they choose to use to demonstrate that their code implements the story and take a view on whether or not I’m convinced by it. But that’s just, like, my opinion. I would like to be able to (build and) run all the solutions using the most vanilla setup—ie, what the download of a recent version give me out-of-the-box—for whatever the target language is. I’d much prefer to do that in a FreeBSD VM. Linux if I must. If you would like to use a .Net language, perhaps you could make sure your solution works with Mono? Maybe I can borrow a Windows machine from somewhere if not.

Practitioners

People will volunteer to be Practitioners will implement stories. Their code will be in a public github repo—sadly this does limit us to languages that have a sensible representation in text files.

Practitioners can work on the problem for as long or as little as they like—but should apply their nominated language, tools and approach with maximum sincerity. I’m more interested in seeing solutions done “right”—whatever that means in a Practitioner’s chosen paradigm—than done quickly. I can generate new stories basically forever—it’s a huge problem space—so we’ll run the exercise until no one is interested in doing any more of it, and then stop.

Solutions should include whatever the equivalent of a Makefile is so that I can build and run them locally.

Assessment

The figure of merit will be not how quickly, in real time, stories are implemented, this is not a race, but how small, proportionately, the impact of each new or changed requirements is on the already existing code.

Volunteer

If you’d like to volunteer to be a Practitioner, please reply to this posting and drop me and John a note on twitter.

There’s no reason why we couldn’t usefully have more than one Practitioner for a given paradigm, but it would be good to have at least one for each of:

• Procedural language (eg C)
• OO in a dynamically typed language (eg ruby, python) with TDD [this is the one I’d pick]
• OO in a statically typed language (eg Java, C#) with TDD
• OO of some sort without TDD
• strict (and eager) dynamically typed functional-ish language (eg CommonLISP, Erlang)
• non-strict (and lazy) statically typed functional language (eg Haskell) in a less polymorphic, more concrete style
• non-strict (and lazy) statically typed functional language (eg Haskell) in a maximally polymorphic, most highly abstracted style [John likes this one]
• Other (eg Prolog, Forth, what the hell: assembler)

Prizes

There will be one prize for the paradigm most clearly superior in the consensus opinion of the Practitioners as interpreted by the Judge (me). And that prize is GLORY! 

The Judge’s decision (ie, mine) is final, normative, and nugatory.

FAQ:

• Am I biased? Yes.
• Do I stand by to be pleasantly surprised? Yes.
• Do you have to take my word for that? Yes.

If this does come off, I’ll attempt to find an academic interested in doing something with the repos.