Tuesday, March 08, 2011

Continuous Delivery and Marginal Consumption

I've recently been reflecting on the similarities between the concept in Economics of charging at the margin of consumption and continuous delivery in software. In particular, I've been thinking about them in terms of the effect each has on the promotion of socially responsible behaviour.

For example, in your college years you probably recall parties for which entry tickets were expensive but that once admitted, all drinks were free. People who went to these things didn't consider behaving in a socially responsible way because the system of incentives motivated them to drink too much. After all, you've got to get your money's worth and the delayed nature of the consequences mean that the hangover is not at the forefront of your mind. If instead, the ticket for the party were free and each drink was individually purchased at the full market rate, this charging at the margin of consumption produces a system of incentives which yield more socially responsible behaviour. There's no longer the feeling among participants that there's a free lunch (or drink) to be gamed.

The parallels with continuous delivery are quite striking. Just as party-goers to the 'all you can drink' party don't focus on the delayed consequences of irresponsible consumption, developers in a software organization which delays the production deployment of code don't focus on the delayed consequences of inadequate testing or other expedient measures in the development of software. This problem is easily compounded in cases where the traceability of those bugs is difficult. This is akin to nobody being able to tell who was responsible for the pools of sick in the morning.

1 comment:

Anonymous said...

That is a very apposite comparison. Developers often aren't incentivized to worry about whether the software is deployable, maintainable, or even useful. The sooner you get stuff integrated and into production, the sooner you're forced to think about these concerns, and the sooner you can get feedback on whether you've created a system that is useful or whether you'd be better off doing something else.