General nonsense

A wonderfully useless piece of software

The Dharma Initiative hatch clock reproduces the countdown clock from the second season of Lost, complete with sound effects and a terminal to type the numbers into to reset it. For the full experience, you can even set it to disable system sleep, so you really do have to “press the button” every 108 minutes (although as far as I can tell it doesn’t actually do anything dreadful if you let it run down!)

Utterly pointless, but nicely implemented and strangely compelling.

[Update] It does become slightly less compelling when you accidentally shut a cat in the room, it walks over the keyboard waking the machine from sleep, and you get woken at 4.30 AM by the “one minute to go” klaxon.


Highlighting scope change in burndown graphs

I’ve just come across an old Agile Chronicles post about burndown patterns, which makes the following observation:

Flat-line (i.e., zero net progress) – a flat-lined burndown chart may have a number of explanations:

  • The team may have been pulled to work on other projects or priorities (i.e., another project, support and maintenance) and has left the current project helpless to succeed.
  • The team may be completing work at an expected rate, but new features and/or tasks are being added to the iteration or project as fast as work is being done.
  • Defects and rework may be preventing real progress from being made.

We looked a while ago on our project at how to make at least the second of those possibilities explicit on the graph, and came up with a simple solution, which I thought I’d share here. I’m sure it’s not original, but it doesn’t appear to be all that common either, so someone might find it useful.



Some people tend to raise their eyebrows a little when people talk about agile software development being more “fun”, and question whether something you’re paid to do can, or should, be fun.

Agile Java Software

An alternative approach to creating specs from JUnit tests

I’m a convert to Behavior-Driven Development, or BDD, as championed by people like Dan North and Dave Astels. As a first step, I wanted to be able to generate a report from an existing collection of JUnit tests which read more like a set of specs (this would be in addition to the normal success/fail/error report), which would in turn be an encouragement to think in terms of behaviour specification when writing tests for new functionality.

To begin with, TestDox looked like just the job. Unfortunately, when I tried it I came across a few things that weren’t quite perfect for my situation:


Prototyping GUI changes

I like low-tech prototyping solutions, and here’s a simple (some might say trivial) one that worked well at a recent release planning meeting, for discussing some minor GUI changes with the users.

Agile Rants

Warning signs that people don’t really understand agile

With “agile” becoming increasingly popular as a buzzword, and with more companies adopting agile methodologies as official policy, it’s common to find people claiming to be more agile than they perhaps really are. This may be either through misunderstanding, or deliberately in order to claim compliance with a corporate target. Here a few things I’ve come across that set warning bells off for me.