Comments on: Perpetually Almost Finished Projects

By: EQ4PM

EQ4PM — Sun, 23 Sep 2007 13:35:44 +0000

Carnival of Project Management #13…

Welcome to the 13th Carnival of Project Management! I am excited to be the guest host for the Carnival this month for Elizabeth Harrin this month as she moves house as they say in the UK. I received numerous great…

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 08 Aug 2007 05:42:51 +0000

Thanks guys for reading and commenting! There are definitely benefits (at least in software) to defining what it means to be done. Test driven development (and behavior driven development) are two approaches to this. Define the criteria for “done” – and when you meet those criteria, you are done.

When thinking about music, I guess that’s the value of having a good producer. Someone who can make a subjective call of “good enough” (and more importantly – not good enough). It also re-emphasizes the challenges of determining the ROI of design that we wrote about last week. How do you quantify “better”? We talked about that some. But how do you justify, in advance, making it better?

Great software development is still both an art and a science.

By: Adam Thompson

Adam Thompson — Wed, 08 Aug 2007 02:17:21 +0000

Excellent post. I’ve used the technique(s) you mention some, but I need to use it rigorously.

This is something I deal with in music in the way that Franck mentioned – a piece of music is never finished. I can always improve an aspect of my singing or playing. But it reaches a point where you have to say that it is good enough.

By: Franck

Franck — Tue, 07 Aug 2007 19:42:54 +0000

The tortoise story remembers me of some math courses ;o)

In reality there are people that can decide that something is “good enough” and then you stop. You should ask the question if it is “finished”, because usually you could always perform additional work.