Frank Carver’s Punch Barrel

An interesting analysis from the New York Times of the progressive replacement of traditional fixed-line phones by mobiles.

The Count - Users Are Tossing Their Landlines Overboard - NYTimes.com

update: a similar conclusion about the European market

A fascinating counterpoint to Gojko Adzic’s writings on acceptance testing in an agile process.

thekua.com@work » Automated story-based acceptance tests lead to unmaintainable systems

Update: here’s some more discussion on this topic, and how it is affected by the nature of user stories

User Stories are Just Schedulable Change

pair programming is often one of the hardest things to “sell” when implementing XP or an XP style approach to development. Mark Needham has written a nice summary of some reasons for choosing pair programming.

Pair Programming: What do we gain from it? at Mark Needham

An article with some good tips on avoiding a clash of cultures between developers and testers on an agile project. (note, there may be a click-through ad on this link)

Software testing on an agile project: How to get started

I’m going to have to read these articles. Jason Yip recommends Geeking with Greg: Early Amazon as a fascinating insight into the inception and growth of Amazon.

Steve Freeman has put together one of the most thought-provoking software development articles I have read in a long time - based on application of ideas from a New Scientist article.

Husbanding willpower | Steve Freeman

An example of poor usability on what should be a transparently simple device.

Meme Agora: Remote Usability

We use ant, a lot, but I’m getting progressively fed up with it so I’m looking for alternatives.

Ant has several well-known problems, including:

• The use of XML makes the syntax very wordy and hard to read
• Things which should be simple such as refactoring common “code” or transforming filenames are more difficult than they should be
• The disjoint between ant xml and custom tasks is very sharp; custom tasks are second-clas citizens
• The built-in tasks are not designed for extendability

I have recently investigated three alternatives:
gant, gradle and pjmake. Gant and gradle both aim to replace ant with a build system scripted in interpreted Groovy. Pjmake aims to replace ant with a build system scripted in compiled java.

Working in a company which is very much involved in mobile and digital music publishing I’m always interested in how other parts of the industry views the key issues in this field. It seems like a few people got together for a conference on this topic on 23 September in London. Here’s a few links about the event

EconMusic - the economics of digital music : Blogs : BCS

EconMusic Video: Billy Bragg In Reuters’ Conference Wrap-Up

EconMusic: Direct-To-Fan: Radiohead, Marillion And The End Of Labels

From time to time I toy with the idea of writing a book. One of the things which has put me off is the whole “big project” nature of the task. I am so used to test-driven, small-iteration, early-value working that slogging away for six months or a year on a single task seems particularly daunting.

An interesting possible solution to this is the idea of writing in an agile manner.

InfoQ: Can Authors Use Agile Methods?

This is just cool, in a “don’t know what I’d actually do with it” way. A port of the Squeak Smalltalk environment to the IPhone and iPod touch.

iSqueak Wikki: Home of the iPhone/Touch port of Squeak

If you see this, it means I have not written a blog post on this site for 24 hours. There’s no need to report me missing, though. It’s just a test of a new plugin I have installed on my Wordpress blog.

The Post Queue plugin monitors post history, and if nothing is posted for a configurable interval, selects one from a pool of pre-written articles and posts it. This post is one such canned article. I originally wrote it on 12 September 2008.

Post Queue :: Shiny Things

This story really resonated with me. We often suffer the same problems described in the article - frequent interruptions and panic priorities, continual flip-flopping of overall direction and dissatisfaction among stakeholders.

The solution we adopted was to choose fixed three-week iterations, with an iteration planning meeting (theoretically including all the stakeholders) just before the development start of each iteration to select a set of tasks totalling a specific number of “jelly beans” (a.k.a ideal engineering days.)

This approach has certainly solved some of the problems, and highlighted others. Interestingly the current iteration is different. Several key members of the team are out of the office this week, so we chose to run a single one-week iteration with a clear goal for a single stakeholder rather than take a productivity hit on the start of a three week one. This iteration has a quite different feel.

perhaps we should also consider reducing iteration length, to see what happens!

InfoQ: Presentation: Extremely Short Iterations as a Catalyst for Effective Prioritization of Work

There’s a certain amount of “duh” in this article, but what fascinates me is not that reading and writing text messages while driving is a distraction (there’s that “duh” again), but the statistics of how many people do it.

BBC News: Text driving ‘worse than drink’