Scott Hanselman's ComputerZen.com

Excellent podcast. It's always good to hear from Ken. Thanks for getting him on the show!

DONE is after listening to Ken for about 3 minutes and 30 seconds. The new question is now WHY?

This podcast is really tightly linked with the previous one.

Ken's focus on the definition of "Done" may seem arduous to some, but it's really at the foundation of the biggest problems espoused in the software development world. At it's very base, most software developers have a ridiculously difficult time delivering "successful" projects b/c there's no agreement on what it means to be "done". (See previous podcast for varying definitions of "success").

Of course, this is the very same thing you talked about with Tom and Mary, just cast in a different light. They talked about "success", Ken talks about "done", but it's all different levels of the same core idea. I think the fundamental problem is simply that we're all still used to building bridges and not managing living organisms. Software is alive and it's an art / science.

The techniques for managing a piece of living art are still not very well-known. All I can tell you is that it's pretty hard. I listened to Tom and Mary's podcast twice and it's very insightful in terms of management decisions. But I still don't think that they've "got it" right on.

I think the biggest problem is the same problem we have trying to manage our own "living piece of art", the human body. The process is non-deterministic, it varies by scale and it varies by variables we can't adequately measure. One man's poison is another man's panacea, groups of humans behave differently in different numbers and they behave non-deterministically.

The life of software is like the life of an organism and raising software will continue to be as difficult as raising children :)

I think that any professional software developer/engineer/coder -- whatever you may call yourself -- should find value in this discussion. "Done" indeed underpins the working contract between developers and customers -- excuse me, "product owners."

I found the discussion of the "programmer's metronome" quite interesting. I can agree to some extent as I've many times felt that nagging feeling of I'm-wasting-my-time-doing-this-other-stuff-and-not-getting-any-code-written! But, I'd like to point out that there are programmers that are not always driven by the metronome, but are forced to cut quality because of broken software development processes.

I've often tried to described software development to others outside the practice as akin to being an artist -- this after they are amazed that I have many artistic hobbies and interests. It's that whole "creation" thing Scott and Carl Franklin (another coder with artistic tendencies!) discussed in Hanselminutes #115. I think some programmers with artistic tendencies, at times, tend to not want to do the other stuff (administrative crap), because it's the aspect of creation that fuels their fire -- myself included.

That said, I personally often have an urge to get that "quality" of the code just right, too, and am not always driven by the metronome. This is an activity that does not introduce new features into a product and is not coding-centric, but there is a sense of accomplishment that follows, knowing your code is tested, refactored, readable, documented, etc. -- good enough for release. It's been well crafted. I think there are many programmers out there that would agree. However, when viewed from a non-software developer's perspective, this type of activity is not generally valued in many organizations for obvious reasons: it doesn't produce any perceptible features or anything even measurable -- at least in more traditional waterfall-like processes.

Again, this only reinforces the point that having a common definition and understanding of what "done" is, accompanied by good agile practices provides the better path to success -- oh wait! We need to define that, too.

Hi,

Thanks for sharing this pod-cast. A colleague pointed me to it and is great fun listening. And you are so right - both of you.

Alex

Hi Scott,
This has definitely been a great podcast to get discussions flowing on what is done.

Here's a message from my boss that I was wondering if you could help me find something out on:

Schwaber says he has a punch list of 40-45 items that conceivably need to be completed before done (eg: procedures, training, regression testing, etc). I would love to see that list. That would set everyone on a level page for defining the type of work that would need to be included as scope of the story.

Finding that list would sure be beneficial, now that the boss is asking for it!