Sunday, February 03, 2008

Small groups and big systems

This story about the US Democrats, and specifically the Obama campaign, and their strategy based on small, autonomous campaign groups working from a honking gurt database of voters, hooks into something I've been thinking recently; in all kinds of fields, it's all about big enabling systems that small autonomous organisations can benefit from. This is some of the thinking we're using at Telco 2.0.

Compare this story on the US Army's monster computer project that is meant to do everything and make your brews while quietly optimising the genome of passing dogs, or something along those lines; I'm not sure whether it's doomed because it includes over 63.7 million lines of code, or whether it's doomed because they reckon counting lines is a sensible metric at the level of the whole project. "Code is not produced, it is spent", as they say.

This Hit & Run post gives me the feeling that Rudy Giuliani's campaign may have been the last great TV politics campaign, the direct opposite of the kind of thing discussed in the first link; buying votes with junkmail and ad spending.

2 comments:

Anonymous said...

(trying again; apologies if this posts twice)

The idea that code is spent rather than produced sounds interesting, but I'm not entirely sure I know what you mean by that. Can you point me toward a brief explanation?

Alex said...

It's one of Teh Thoughts of Edgar Dijkstra.*googles* Ah yes, here it is: On The Cruelty of Really Teaching Computer Science.

The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

kostenloser Counter