The latest issue of The Economist has an interesting leader called “The end of the cash era”. One of the themes picked up by the article is the power of anonymity, the anonymity inherent in cash. Elsewhere in the article, the writer speaks of the current tendency to trade privacy for some form of implied convenience.

Those of you who have heard me speak at conferences would already be familiar with some of my views on privacy, particularly the difference between eastern and western conceptions and views.

What intrigues me about the article is its coda. I quote:

As Adam Smith would no doubt have observed, just because the state can pry into electronic cash does not mean it should.

I think this is important, and at the heart of many digital debates, including DRM and Identity: Can versus Should.

Region coding on DVDs is a classic example of someone doing something incredibly stupid because they could. Illegal capture of clickstreams is another.

When I first read Lawrence Lessig’s Code, my biggest takeaway was the potential loss of liberty.

We have to be careful. Careful to ensure that the individual, the “customer” of the state, has his rights protected. That information about intentions and behaviour and preference and attitude and expenditure patterns and earnings and and and, are all protected. Otherwise governments will do their equivalent of region coding. Because they can. Not because they should. In fact, because they shouldn’t.

More later.

The blogosphere delights me. I think it’s wonderful, the way things can emerge as a result of different perspectives and experience and ideas acting on the same “theme”. Let’s take a simple for-example:

A short while ago I was musing over a classic problem to do with Agile: the traditional human desire for predictability, how that often influences the creation of flawed plans, how it is that the flawed plans then get funded, and the consequent militant standoff between the Plan and reality. I shared my belief that the thing we had to change was the “contract”. I referred to some work done many years ago by Alistair Cockburn, meandered towards some other stuff (on incomplete contracts) done by Erik Brynjolfsson, and suggested that the answer may lie in something we have yet to see work commercially, a software development contract based on option theory.

A reader I’ve never met (and I’ve met a goodly number), Andrew Ochsner, then commented on how he had been looking serendipitously at something similar, and referred me to a paper by Kent Beck on Optional Scope Contracts. [Thank you, Andrew]. Now I’d read the paper before, but with the blogosphere, I don’t have to go through the process of remembering it, trying to find it, checking its relevance and then publishing its availability. There’s a community that does that, focusing on subjects we care about, but, importantly, subjects we do not necessarily have the same opinions about.

I’m still working my way through Kent’s paper, but what intrigues me is the implication of making quality a constant. For quality read customer satisfaction. For contract read covenant. Suddenly I get very very interested.

A note about contract versus covenant. In a contract, at the slightest sign of trouble, you look for “recourse”. A contract tells you how to punish the other person if something goes wrong. In a covenant, at the slightest sign of trouble, you look for “repair”. A covenant tells you that the two of you will work something out, not sue each other.

The relationship between developers and “the business”, in an Agile setting, must be a covenant. Not a contract. And the common theme that binds the two parties together must be customer satisfaction.

More later.

Thanks to John Wilson for letting me know about this conference. If any of you is interested, there’s still time to register.

I intend to attend the following sessions:

• Take Control of Your Team’s Decisions NOW! by Ken Schwaber
• Avoiding the Seven Pitfalls of Lean by Mary Poppendieck
• Pair Managing: Two Managers per Programmer by Jim Highsmith
• Two-Phase Waterfall: Implementation Considered Harmful by Robert C. Martin
• User Interaction: It Was Hard to Build, It Should Be Hard to Use by Jeff Patton
• FIT Testing In When You Can; Otherwise Skip It by Ward Cunningham
• The Joy of Silence: Cube Farm Designs That Cut Out Conversation by Alistair Cockburn

There’s something in it for everyone, and it comes well recommended. Do cascade the information to others who should attend.

One has to be careful with the word “agile”. If you were an accountant, how would you feel if someone described you as agile? Other than in the pure physical sense, I guess.

I digress.

I’ve experienced a lot of pushback whenever I’ve seen agile techniques being used, perhaps even more pushback than I’ve seen for social software as a whole. When I’ve tried to analyse the sources of the pushback, the Conscientious Objectors can be classified as follows:

• The In-Concrete Setter: I need robust reliable plans, not all this mumbo-jumbo. I’ll give you use-case.
• The Futurologist: I have a long-term business to run, with long-term plans. You’re just not helping me. Get real.
• The Educated Dinosaur: Just tell me what I am going to get, when and for how much. Is that too much to ask?
• The Legless Ostrich:  You’ve known about this for at least a year now, how can you say this is new?
• The Mad-Hatter-In-Reverse: (A close relative of the In-Concrete Setter) You’re late, you’re late, for a very important date [with apologies to Lewis Carroll and, if memory serves me right, Danny Kaye]

Much of Agile is about the most effective way of discovering amorphous requirements. Agile does this in many ways: use of user stories, fast iteration models, pair programming, collocation in general, better in-team communications, more bite-sized chunks of work, test-driven design, natural selection, whatever.

All these techniques are designed to make the software meet the user’s expectations in terms of function and look and feel and even performance.

Where Agile is sometimes oversold is in the context of estimation. To me, software estimation is a bit like growing ear hair. It takes time to do it well. There aren’t that many short cuts.

And when you look at the conscientious objector list above, you will find that most of them have the core of their objection rooted in the lack of predictability of planning. For some reason they seem to forget that they never had real predictability with the waterfall model, especially not when requirements were amorphous or tacit.

I’ve been wondering about how to fix this for a while, and many years ago this drove me down an odd road, looking at Erik Brynjolfsson’s work on Incomplete Contracts. I kept on feeling that until and unless we managed to capture the value of Agile (although it wasn’t called that then, we just used terms like Fast Iteration) in a comprehensible contract, we would always face an uphill task.

So it looked like we would be stuck with Predictably Wrong rather than Provisionally Right.

Which is why I found this piece on Agile Contracts by Alistair Cockburn a timely reminder to delve deeper into the Agile contracting process. Alistair lists 10 contract types:

• Fixed-price fixed-scope (and possibly fixed-time)
• Fixed-price fixed-scope (and possibly fixed-time) but collaborate with the customer to alter scope anyway
• Time and materials
• Not-to-exceed with fixed fee
• Fixed price per story point
• Bob Martin’s idea, an updated version of shared-risk shared-reward model
• Venture-capital financing model
• Incremental delivery with payment on incremental acceptance
• Jonathan House’s idea, fixed-base-price with success/failure ratchets
• Time and materials variant

I tend to think the answer is in none of these, but in option theory. I’m not the first to think that way, but what Alistair has done is reawaken in me the need to complete that analysis. So thank you Mr Cockburn.
I’d love to hear from readers about their experiences in this regard. Any takers? What works? What doesn’t? Why?

I thought this was wonderful, the kind of stuff I wouldn’t hear about except for the Web. Take a look at this site, where someone is selling merchandise consisting of animal shapes traced on the iconic London Tube map.

Thanks to Konrad for the tip-off. [Yes, I make it a habit to visit blogs that link to me, more out of curiosity than courtesy, but a combination nevertheless.]