September 2005

« August 2005 | Main Index | Archives | October 2005 »

30
Sep

So the Evolution vs Creation debate is going to court again in the USA1, and there are predictable outbreaks of reason across the blogosphere.

At the centre of Intelligent Design is the following core: "There are enough gaps in the theory of evolution that it may be wrong. In its absence, any other plausible theory2 could be correct. Here is our plausible theory, which coincidentally agrees with a few thousand years of Judeo-Christian theology." As others have noted, you could make a similar argument about any counter-theory.

The most interesting thing to me about Intelligent Design, though, is that if you look too closely at it, it's an argument against the Christian God. If you look at the human body, which was supposedly designed in totem rather than evolved, there are so many bits that are useless, inefficient or even counterproductive that we hardly fit into the ideal of being constructed out of clay, so to speak, by a perfect and beneficent God.

Philosophically speaking, a far better fit for Intelligent Design can be found in the Gnostic Demiurge, a flawed and possibly malicious creator who built the world while God wasn't paying attention.

Maybe it's the programmer in me who wants to agree in a way with Cameron's tongue-in-cheek response: that the Universe was created in a 'single line of code', in a single idea, a single law so pure that once set in motion it alone could bring about all that we see when we open our eyes, and all that we don't see when we close them.

Maybe that 'one idea' is God's creation, or even that idea is God Himself. But if it is, He's not going to need to meddle with His creation. He's not going to ever-so-carefully lay down false evidence that the Universe is one thing when it's truly another. And He's not going to create a Universe based on rational laws, then not want us to practice our rationality.

1 I like to explain the schizophrenia of the USA on religious matters as the result of a bunch of pilgrim settlers who left England because the Church wasn't hard-core puritan enough for them3 founding a nation founded based on (amongst other things) religious freedom.
2 This sentence just goes to show how easily you can switch between different definitions of 'theory' if you're not careful.
3 This is, of course, about as accurate as saying Australia was settled by criminals, but I'm going to run with it anyway because it's such a convenient explanation.

Coming here from TrackStudio's JIRA comparison page? You might want to read this first.

When, as we do, you write your specs on a wiki, keep track of your development tasks in an issue tracker, and eventually ship products that only exist as bits downloaded from a server, it's very easy to forget how much psychological impact physical objects can have.

Data exists in some ether that your mind never really has to deal with completely. Physical things have presence. They take up space. They can arrest your vision. When you move them they stay moved. You can fold, spindle and mutilate them as you wish.

Which is why the 'Wall of Death' is such a useful tool for getting developers focused on the task at hand.

Step 1: Preparation

All the issues marked as outstanding for the next release are printed out, two to an A4 sheet of paper. We find JIRA's "Full Content" navigator view works well for this, although you have to print through Opera, because no other browser correctly supports the CSS hint for a form-feed.

Step 2: Lightning Estimation

The issues are divided between the developers, who are asked to estimate their pile purely on gut instinct. Developers are free to swap issues if they feel someone else is in a better position to estimate a particular task. Estimates start at half an hour, and then increase roughly exponentially: one hour, two hours, half a day, one day, two days, four days, two weeks.

Estimates are written on the printed issues in some bright, unmistakeable colour.

Step 3: The Cull

Now you have your issues estimated, it's time to go through them again and make sure there is at least some sanity to your schedule. Add up all the estimates, compare them to when you feel you want to release, and cull your issues until the former fits into the latter.

Step 4: Build the Wall

Find a stretch of uninterrupted wall in easy reach of the whole development team. Blue-tac all the issues to that wall, grouped in vague areas of functionality. Also, co-opt a corner of a nearby whiteboard to hold the tally of estimated time remaining.

Step 5: Go!

This step takes a little more time. :)

The rules of the wall are:

  1. Developers take an issue off the wall, and work on it until it is done
  2. Developers must not work on anything that is not on the wall
  3. Corollary to rule 2: unanticipated additional work must be filed in JIRA, then written on a card and placed on the wall
  4. Developers must never take more than one issue off the wall at a time
  5. Once an issue is done, the developer records the actual time taken in the other corner of the issue, dumps it in the 'done' pile, and updates the whiteboard.
  6. Repeat until no issues remain on the wall

Why it Works

I'll be the first to admit that this idea is stolen largely from the way Extreme Programming uses index cards, just adapted to an environment that takes advantage (for good reason) of an issue tracker, and where the time-boxing of an iteration is often subject to the commercial necessities of having a complete, polished release.

  • The wall focuses the team's attention on just how much work exists between now and the release
  • The temptation to pad out features or to experiment is countered by the desire to mark the issue as done, and pull the next off the wall
  • The state of the wall is a clear indicator of progress, and as it empties there is a palpable feeling of satisfaction
  • Scope-creep is much harder when in order to accomplish it, you have to put a physical object that means "more work" in plain view of everyone, and adjust the whiteboard tally upwards
  • As a bonus, you end up with a pile of paper that records differences between estimated and elapsed time


Update, September 1 2007. I was checking my referrer logs today, and found that this post had been linked from TrackStudio's comparison page for JIRA with the following text:

Choose TrackStudio if you are going to use the system both to organize work inside your company and to communicate with your customers. Atlassian developers uses JIRA primary to communicate with external users, but they do not use it to manage software development (you can read details here and here).

Not only is this statement patently untrue -- we use JIRA at Atlassian to manage software development. We also use it to track support, sysadmin tasks, even ordering books for our library -- it completely misrepresents the content of both of the blog posts it linked to. I guess they figure that most people won't bother to click through the links and read the posts for themselves.

I humbly suggest you read the remainder of their product comparison with a similar grain of salt. :)

Programming is looking at a feature request in the morning, thinking "I can do that in one line of code", and then six hours later having refactored the rest of the codebase sufficiently that you can implement the feature...

...in one line of code.

Name: Benefit of the Doubt

Context:

Some party has done something of which you disapprove, but you can only guess as to their reasons for doing so. You wish to achieve an outcome where the behaviour is not repeated.

Forces:

  • The natural response to aggression is defensiveness, which leads either to a shutdown of communication, or to counter-attack
  • Accusation and counter-attack lead to third-parties being forced to take sides, causing collateral relationship damage, and a possible spiralling out of control of the situation

Therefore:

Express your displeasure with the behaviour of the party in the wrong, but do so in such a way that places a favourable interpretation on the reasons for their actions. Suggest that their actions were obviously an unintentional mistake, or were done for good, but misguided motives. This way you offer the other party the opportunity to repudiate their own actions, but to save face in doing so.

Ultimately, there are four possibilities:

  1. The guilty party's actions were indeed mistaken or innocently misguided, in which case reparations can be made without malice.
  2. The guilty party's actions were malicious, but they do not wish to admit fault. The benefit of the doubt gives them a convenient fiction under which to apologise or make amends, returning things calmly to the status quo.
  3. The guilty party's actions were malicious, and they wish to admit fault. Offering the benefit of the doubt makes you look generous, and gives them the chance to appear to be behaving honourably by admitting fault and making amends even when they were not accused of it directly.
  4. The guilty party's actions were malicious, and they really don't care about making amends at all. You still look good for playing the diplomat, and their malice is placed in sharp focus against your generosity.

The only danger lies in the second outcome, where malice is allowed an easy excuse. In the short term, this is beneficial as it places the guilty party on notice that they're at least going to be called on their misdeeds, without overwhelming the situation with bad blood. On the other hand, though, it can be taken advantage of, which means you have to be careful you do not offer the benefit of the doubt too many times.

As a great thinker once said: "Fool me once, shame on you. Fool me... you can't get fooled again."