Goal Stack

A PairProgramming technique. As the navigator thinks of another test to write, or something that needs attention within the pairing session, the navigator is responsible for remembering this, and pushing it onto a "stack" rather than interrupting the driver's flow. Usually this is done by writing it down, since the stack grows quickly. -- RobMyers

There is already a page called PushDownGoalStack - is this the same thing? -- MikeSmith

No, it's more a discussion about using a goal stack for managing one's priorities, and it degenerates more into the pitfalls of the simple stack, and one man's descent into AnalysisParalysis.

Another contributor summarizes it like this:

I believe that accomplishing business, project, or life goals depends on scheduling time slices for the things that must be done. The stack model has limited utility in the long term or in a broad scope. It's useful in confined situations, but in larger contexts you can achieve "stack overflow" failure.

Even for the XP navigator, there are recommendations on using a GoalPool? instead of a straight GoalStack; as well as applying more intelligence and perhaps a bit of serendipity through SoftlySoftlyCatcheeMonkey.

-- DerekWoolverton

We use the term "stack" because we found that we were addressing the to-do list in that order. We would write a test for one object, and realize that we needed to push behavior to a different object "first" (or use a MockObject). So we would delve into deeper levels of detail, and we wanted bread crumbs to lead us out.

Of course, if you try to live your life based on a computer algorithm, then you're doomed. As we looked at the to-do list, we could certainly jump around. Also, we would draw a little box near each item. Things that got done would receive a checkmark, and things we chose not to do (because they had become unnecessary) would get an X. -- RobMyers

I started the PushDownGoalStack page. I saw the PushDownGoalStack as a phenomenon wherein the goals one seeks to accomplish seem to require that one accomplish some other goals first, and those in turn require one to accomplish other goals before those, and so forth. Thus, the page was not intended to present a problem-solving method, but to present an observation about the stack-like nature of the problems themselves. The only things you can do about stack-like goals are (a) permute the goals in various ways to shake out dependencies that may appear necessary but really aren't, (b) use the work of others to skip steps, or (c) just accept the stack-like nature of the goals as a necessity, and work through it.

(All right, so after observing that nature, I griped about it. Shouldn't have done that, sorry, but that was two years ago and I was more naive then. I'm afraid to delete the gripes even now, because I'd have to delete a lot of other people's responses along with them.) -- EdwardKiser

I didn't mean to be critical, I was just trying to answer the question about what information PushDownGoalStack provided. (Ok, maybe I was feeling a little critical, since MikeSmith asked a question which he could have easily answered himself.)

The page itself provides some utility as a warning to others, and is worth reading. It's just not a good place to go to find out more programming strategies.

-- DerekWoolverton