Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, January 4, 2013

Thinking, Doing and Redoing

I've been working on software development projects and standards projects for decades.  One of the things I've learned as a developer about these projects is that you aren't done until you've shipped.

For software; code complete isn't shipped, sent to QA isn't shipped, and finishing Beta isn't shipped.  Shipped means that the CD is in the customer's hands.

For standards, sent out for ballot isn't shipped, passing ballot isn't shipped, and negatives reconciled isn't shipped.  It's only when the final text is in the customer's hands that you've hit shipped.

A typical project (regardless of domain) spends its time something like this:

⅓ Thinking
⅓ Doing
⅓ Redoing

It's the redoing part that's really hard.  That's where the feedback that you get from QA or from customers, or from a ballot has to go back into the product.

There's very little you can do to make redoing take less time as an overall fraction of your project time.  You can move feedback earlier into the project (as iterative approaches do), but what that winds up reducing not just "redoing", but also "doing" and even "thinking".

So, if you are in the middle of a ballot process, try not to think of yourself as being nearly done.  You are just at the halfway point.  When the ballot is over, and you start implementing the feedback, you'll be about ⅔ done.  When you've made all the changes from ballot feedback, then you are "nearly done", but remember, it isn't until the specification is in customer's hands that you've reached complete.

One other thing:  A standard isn't really done until its been implemented, and is in your customer's customer's hands.  That's a whole 'nother project (or a bunch of separate projects running in parallel), so when you've put it into your customer's hands without a pilot, you're only about halfway done.

-- Keith

1 comment:

  1. As I read your post I couldn't help but push the definition of DONE out further. I would not call anything done until it has been USED. Shipped but not yet used is as good as not shipped. I might not call it done until it has a bug reported against it. As with software so with standards, there is sure to be a bug in there somewhere.
    You did hit upon this in your last paragraph.