22 September 2007

Voting on implementation effort

I was recently at the International Conference on Information Systems Design at the National University of Ireland in Galway. One of the more interesting presentations was from Hans Mitlöhner. He suggested that you could use ordinal rankings and voting rules to develop effort estimates for software development projects with comparable accuracy to the more complicated but well known COCOMO method* (here are the slides and the paper). It was an interesting idea but I think it requires a slightly different focus to be an effective estimation technique.

The idea was that you could think of each of the different COCOMO attributes as a voter. Each of these attributes (or voters) ranks the new project relative to the other projects. So for instance you rank all the projects based on the required reliability, then on programmers' capability and so on. These rankings (or votes) are then aggregated based on voting rules: simple majority, maximin, copeland or borda. Based on these rankings you can come up with an accurate estimate for how much effort it will take to develop the software. Using, for instance, simple majority voting and just 5 of the COCOMO attributes
(reliability, turn-around time, analyst's capability, programmer's capability, schedule constraints) this method produced estimates of comparable to the full COCOMO method (i.e. 30% accuracy).

It is presumably easier to rank projects rather than to calculate the attributes completely. Coming up with a numeric estimate for some of the COCOMO attributes is a time-consuming and produces precise numbers for things that are somewhat ambiguous in nature. For that reason its plausible that coming up with a simple ranking will in many circumstances be easier and more transparent than using the normal COCOMO method.

In my view, there are two problems with the method:
  • Most companies won't have enough projects to come up with a representative sample that could be used to apply this method. This estimation method seems to require a reasonable number of cases to be used as reference points that the people in the project are familiar with before it is applicable.
  • Even if they do have enough projects that the method could be applied effectively, would there be people in the company with enough knowledge about each of those cases that they could ranking each project accurately on each of the attributes.
Where I think this method may, however, be useful is in aiding the estimation of work effort of "cards" in extreme programming. In extreme programming techniques changes are written out on cards which are then assigned an effort estimate. These effort estimates are usually based on the intuition of the software developer. In my current workplace we have a problem that these estimates aren't terribly accurate and that there is a large optimistic bias (we usually estimate too little time for each card rather than too much).

Each week we work through a fairly large number of these cards, maybe twenty or so. The developers, especially the developer that worked on the card, can give a fairly accurate ranking of the card's difficulty across different criteria. This means that, while this effort estimation method may not be useful at the level of whole projects, it may be possible to apply it at the level of individual cards. Especially if there was software support for the ranking process to make it easier to apply the method.

The next question I guess is do we really want better estimates of development effort? Some people say no... but that's a topic for another time.

*COCOMO is a technique for estimating the effort required to implement a particular piece of software and was originally developed by Barry Boehm. For more information see this Wikipedia article.

16 September 2007

Peccadilloes of Academic Typograghy: Endnotes vs. Footnotes

In a continuing series on the peccadilloes of academic typography I present the endnote. Being a curious person endnotes in a book or an article really annoy me. I feel compelled to flip to the end of the article and appease my curiosity. Normally I'm let down because its usually just a simple reference or something obvious. Occasionally, however, there's a really interesting endnote, and this is what keeps me flipping back and forth.

The Oxford Press Edition of Joseph Conrad's 'Heart of Darkness' is a case in point. Full of mostly useless endnotes, but, the occaisional gem lies lurking there at the back of the book forcing me to continual look and, almost always, be disappointed. Why can't everyone just use footnotes. It saves wear and tear on the book and satisfies my curiosity immediately!

Labels:

12 September 2007

More than food miles

I was discussing the relative merits of buying local food vs. food that's shipped or flown in with some of the guys at work. My position, which I expressed poorly, was that often the economies of scale or comparative advantage overwhelm the carbon produced by the shipping process meaning that its often better (i.e. more environmentally friendly) to buy food that was grown overseas and flown or shipped in. Fortuitously, I stumbled across this recent NY Times article (via Cafe Hayek) which argues the point far more effectively than I did.

It all depends on how you wield the carbon calculator. Instead of measuring a product's carbon footprint through food miles alone, the Lincoln University scientists expanded their equations to include other energy-consuming aspects of production — what economists call "factor inputs and externalities" — like water use, harvesting techniques, fertilizer outlays, renewable energy applications, means of transportation (and the kind of fuel used), the amount of carbon dioxide absorbed during photosynthesis, disposal of packaging, storage procedures and dozens of other cultivation inputs.

Incorporating these measurements into their assessments, scientists reached surprising conclusions. Most notably, they found that lamb raised on New Zealand's clover-choked pastures and shipped 11,000 miles by boat to Britain produced 1,520 pounds of carbon dioxide emissions per ton while British lamb produced 6,280 pounds of carbon dioxide per ton, in part because poorer British pastures force farmers to use feed. In other words, it is four times more energy-efficient for Londoners to buy lamb imported from the other side of the world than to buy it from a producer in their backyard. Similar figures were found for dairy products and fruit.

Admittedly the research is from NZ scientists comparing NZ products to English products so there is room for bias but the point remains. Its not as simple as tallying up the carbon emitted in transporting the produce from where it was grown to where its being consumed. There are a range of other carbon emissions involved (other than transport) not to mention the fact that local small scale growers are likely to use less efficient and more carbon emission producing means of production. How clear is it that carbon emissions are really so bad anyway?


11 September 2007

A stitch in time...

It took me a long time before I understood the saying "a stitch in time saves nine". I always wondered how a rent in the fabric of space-time could save nine. I guess its just a reflection on my childhood.