Checklists and Design by Contract

One of the problems I am having with checklists is that they are often, or nearly always, confused with processes: "this is the list of steps we have to do and then you tick them off and all is well" mentality. This is probably why in some cases checklists have been renamed "aide memoirs" [1] and why their use and implementation is so misunderstood.

In the case of aviation or the surgical checklists these do not signify whether it is "safe" to take-off or start whatever procedure but as a reminder to the practitioner and supporting team that they have reached a place where they need to check on their status and progress. The decision to go or no-go is not the remit of the checklist. For example, once a checklist is complete a pilot is free to choose whether to take-off or not irrespective of the answers given to the items on the checklist (cf: [2]).

This got me thinking in that there are some similarities to design-by-contract and this could be used to explain checklists better possibly. For example consider the function to take-off (written in pseudo Eiffel fragments [3]):

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     do
        ....
     end
...

can be called whenever, there is no restriction and this is how it was, until an aircraft crash in the 1930's triggered the development of checklists in aviation. So now we have:

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     require
          checklist_complete = True
     do
        ....
     end
...

and in more modern aircraft this is supplemented by features to specifically check on the aircraft status

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     require
          checklist_complete = True
     do
        if flaps < 10 then 
            soundAlarm 
       end
        ....
     end
...

or even:

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     require
          checklist_complete = True
          flaps > 10
          mode = GroundMode
     do       
        ....
     ensure
          mode = FlightMode
     end
...

What you actually see are specific checks from the checklists being incorporated into the basic protection mechanisms of the aircraft functionality. This is analogous to what we might see in a process, for example below we can see the implementation of functionality to encode a project approval checklist into some approval function:

    approveProject
      require
         securityReview.status = Completed
         privacyReview.statuse= Completed
         continuityReview.status = Completed
         performanceReview.status = Completed
         architecturalReview.status = Completed
      do
         ...

Now we have said nothing about how the particular reviews were actually made or whether the quality of their results were sufficient. This brings us to the next question of the qualitative part of a checklist and deciding what to expose. Here we have three options:

1. completion
2. warnings
3. show stopping preconditions

The first is as explained above, the second and third offer us a choice about how we expose and act upon the information gained through the checklist. Consider a privacy or information content review of system, we would hope that specific aspects are specifically required, while others are just warnings:

    approveProject
      require
         ...
         privacyReviewStatus = Completed
         privacyReview.pciData = False
         privacyReview.healthData = False
         ...
      do
         if privacyReview.dataFlowModelComplete = False then warn("Incomplete DFDs!") end
         ...

And we can get even more complex and expose more of the checklist contents as necessary.

The main point here is that if we draw an analogy with programming, some aspects of checklists can be more easily explained. Firstly the basic checklist maxim is:

All the items on a checklist MUST be checked.

then we should be in a place to make a decision based on the following "procedure"

1. Are all individual items in their respective parameter boundaries?
2. Are all the parameters taken as a whole indicating that we are in a state that is considered to be within our definition of "safe" to proceed to the next state?
3. Final question: Go or No-Go based on what we know from the two questions above?

Of course, we have glossed over some of the practical implementations and cultural aspects such as team work, decision making and cross-referencing, but what we have described is some of the philosophy and implementation of checklists in a more familiar to some programming context.

References

[1] Great Ormond Street Hospital did this according to one BBC (I think) documentary.
[2] Spanair Flight 5022 

[3] Eiffel - one of the best programming languages ever