Friday, February 19, 2010

Life-and-death Agility?

-- picture from Space Shuttle Challenger Disaster

A software development life cycle model (SDLC) is a very important tool for successfully executing a software development project, and it’s important to choose the right approach for the right project.  Some of the factors that would go into choosing the right SDLC model are:
  • Risk and Complexity of the Project – you would never choose a very agile approach for building the Space Shuttle software. The risk and complexity of the project is probably the biggest factor in choosing the most appropriate SDLC model for the project. 
  • ...
-- quote from Agile versus “Non-Agile” Development

When I read this, my first impulse was to say "just another old-line management type who doesn't get it".  But now I have an uncomfortable feeling about it.  Do I really believe that choosing waterfall development over Agile is a mistake - that the chances are good that it will come back to bite you?  I do - I'm pretty sure I do.

Then do I believe it would be prudent or even possible to use an Agile approach to building shuttle software?  Would I be a fanatic if I said yes?  Would I be inconsistent if I said no?  Don't I believe that Agile is the best way to deal with risk, uncertainty, unknowns? Can there be such a thing as "mission critical Agile", or are there some things that have to be done "the old-fashioned way"?

I certainly don't want to be a fanatic, but I think that if I don't believe that the best way to build the shuttle is with Agile, then there's something deeply wrong with what I do believe.

If I look at it from the standpoint of user acceptance testing, maybe the issue goes away.  Just as skeptics say, "extraordinary claims call for extraordinary proof",  we can say, "mission critical software calls for mission critical testing".

Suddenly this reminds me of how I overcame my fear of Ruby.  I spent years fighting for type safety, and now you're telling me to start typing like a duck?  I thought I could never trust a language like that. But then I realized that TDD is the answer - thank Dave for Rspec! - and I love Ruby to death.

If NASA doesn't have rock-solid acceptance testing, then it doesn't matter what approach you use - you can't trust the product. And if they do have rock-solid acceptance testing,  you're free to pick the most efficient and effective approach, because your problem is now insulated by the solid walls of a black box.

And the most efficient and effective approach will be ... Agile.

This doesn't mean that things don't have to change:  maybe we'd need a higher level of structuring of testing, above Fitnesse and XUnit and Cucumber and Rspec.  Maybe we need automated requirements traceability, but with stories and tests and coverage testing, not BDUF and humongous documents.

But change is what we embrace, and risk is what we face - with

 [Bert Lahr pic from No Cowardly Lions Please!, which did not attribute source]


  1. A very interesting topic. My blink reaction is that I'd want agile with the most formal and rigorous risk management possible on such a risky project. I think that people mistake "agile" for "risky", possibly because we tend to use the agile approach to cut through bullshit and get as close to perfectly-efficient communication as possible. Sometimes we step off the cliff, and that makes us look like big risk-takers. I don't think we are, necessarily. I think we can run a high-risk project like launching a space shuttle with the discovery and technical excellence practices just as we do them on any other agile project, but with the most rigorous risk management anyone's ever seen. Also, I imagine there's more pure mathematics and physics on a space shuttle (in particular) than the average project, meaning that we have even better data from which to write our tests. I think it would work great. It almost makes me wish I could put a shuttle into space to see how it would go.


  2. Great point about the math and physics. And how cool would it be to have aerospace engineers as customer reps in our standups? Never had much luck getting customers to write Fitnesse tests, but these folks would likely have no problem with it.

    (Unwilling as I am to admit it in the present company, I've used Fitnesse for *cough* integration tests.)