Agile Healthcare Delivery = Failure

Agile Software - from Wikipedia

A couple of days ago wrote a couple of articles on health.  Basically describing my philosophy on taking care of yourself mentally and physically.  A few people read them - less than a dozen.

I also wrote an article on why I though Agile software development was a stupid idea.

Five times as many people read that article.

I find it interesting that developing software with a silly strategy is more important to people than their health.  I have no idea who is reading this blog and certainly most of the interest from my perspective is in the health side - its a topic I write about frequently.

So lets imagine for a moment that doctors used an Agile Development philosophy in treating patients.

According to Wikipedia the Agile Software Manifesto says "Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle."

Let me translate this:

Basically from my perspective you start out with your best "guess" when doing something.  You add to it as best you can to make something "workable."  This goes to the client who comments on it.  You take the comments and anything else you've learned is wrong or could be made better and bake them into your next round of development.  Repeat until the outcome is successful.

Or in another context:

"Gee, Jr. that little Lego car is great, let's put some wheels on it..."

Now if you think about this model  its basically the same thing that happens in the medical world when you have a health problem.

Let's say I show up at the ER with some amorphous pain in my gut somewhere.

Provided that triage does not show appendicitis or similar problems you'll probably be sent home with admonishments to "eat right" and do this or that. And always to "check with your regular doctor." (Iteration #1)

So you go to said "regular doctor" and then poke around a bit and say, "Oh its X" were X is some standard catch-all disease like acid reflux.  Take some Nexium come back in a few weeks, blah, blah blah. (Iteration #2)

You come back four weeks later and say "Oh, that helps some but now my mouth is dry from the Nexium."  So you get a script for Biotene or whatever to fix that.  Mean while the Nexium is destroying your immune system (stomach acid is a big part of your immune system).  You make an appointment for four weeks later... (Iteration #3)

Same idea as Agile Software Development.

I don't know what I am doing so I'll take my best stab at it...

Personally I never really understood this idea.

Now it makes sense in some ways when you are creating a design for something.

A while back I decided to write an App for iTunes (described elsewhere in this an other blogs) call MIDIProbe.

The idea of MIDIProbe was to capture MIDI events in a usable way.

Now I could have just "guessed" at what was needed - did my best to capture what MIDI was about.  Baked that into a release and put it out there.

I then could have waited for customers to find bugs and complain.

Then I could have made another "best guess" and started over.

But I didn't.

I spend A LOT of time with the MIDI standards, device that produced MIDI, etc. so that I actually had a compete and full understanding of what it does and how its used in the real world.  I then went back and made sure my design incorporated all the right functionality from the start.

I also carefully worked out what would need to be displayed about the MIDI messages.  Now this is not as simple as it seems but when you work it all out you have an exact set of data for each message and so on.

In the end the only "customer choice" aspect of the application was the display formatting and operation of the UI.

But it seems like most of the world is lazy and doesn't care to work out details like this in advance.

Now software development got into this state from another state - that of "specifications."

The idea of specifications was that someone would "write out" exactly what was to be done, i.e., basically write the software without writing the software.

But when you think about that you'd really need to fully understand everything in order to write a complete specification: otherwise you'd specify things that might be impossible or impractical for some reason, i.e., take too long.

So then you'd spend an aeon writing useless specifications.

Now medical treatment doesn't use specifications but it uses the same "problem solving" iteration model.

Now on the software side the medical model doesn't work either really.  If something doesn't work typically you actually fix it rather than simply fix the symptom.

SO all and all to me this means that we are not using what we have learned in the last fifty years about problem solving wisely.  In fact, I think to some degree we've gone backwards because at least fifty years ago people were studying these issues and trying to improve.

Today we simply accept bogus approaches as gospel and live with the consequences no matter how silly or stupid.

If you write software to a changing specification how will that work - ultimately the code is not dynamic, i.e., if you write it to deal with adding three things and suddenly there are four things the code simply won't keep up if its hard coded for three.

I think that humanity needs to work out some better approaches to problem solving and debugging.

As I have said before no one that I can find studies this.

Yet it underlies everything from our fifteen trillion dollars in debt to our failed space missions.