29.10.2006
1) Projects have a time structure. One way of putting this would
be to point out that projects start at some time, are carried out over a
certain period of time, and end at some later time than they began. (In some
cases projects have no definite end but 'fade out': activities that make up
the project are de-intensified, perhaps, or otherwise thinned out, until
there is nothing recognizable left of what was once a project.)
While these are characteristics that projects share with other processes,
there are also some more specific ones: projects often spring from the
formulation of a goal, or they are motivated by one or more desires. Goals
and desires have a time structure of their own, which influences that of
the project. For example, connected to a desire is usually an imagined
future situation in which the desire is fulfilled. Formulating a goal
means, similarly, to specify (more or less explicitly) a future state of
affairs that is to be brought about. Thus devising a project involves, at
the beginning, some future-pointing elements.
Moreover, the activities that unfold during the pursuit of a project
have, as reference points, various similar forward-pointing elements. These
can be intermediate goals, or experimental paths that are followed for
a while, or perhaps deliberate delays (wait for things to develop further
before taking action). There are also backwards-pointing time-structured
elements that play a role in projects: elements of review, or regret, which
might trigger course corrections.
These time-structured elements make up the background of an ongoing
process. The structure is not purely temporal, though. The steps that
have to be taken as an ordered sequence of moves, where each of them is
dependent on some of the preceding ones, can be described without reference
to the time structure itself. Here is an analogy: think of the opening of
a game of chess. Although in chess tournaments an amount of time is allocated
for a given number of moves that a player can make (and it might have a real
impact on a player if that time is running out), there is nothing in the
moves a such that has a temporal structure. They could be written down and
replayed in order, but not necessarily with the same time intervals between
them as when they were originally played.
In fact, the structure of projects might include such elements that
imply an ordering only (some intermediate goals must first be reached for
further project stages to begin), whereas others included in it have a
temporal (that is, a durational) aspect in addition to that. What
makes elements in the structure of projects temporal is that a certain
amount of time will necessarily flow by for each step or stage in the
project. Sometimes this will be in the trivial sense that a minimal execution
time of each step has to be considered, but there are many situations in
which this aspect becomes much more interesting. Take, for example, the
psychological impact that a forced delay may have on an agent ('Never let
the strain of inaction alone be your stimulus to action' is a well stated
advice that a character in Reginald
Hill's novel Arms and the Women gives.) Or consider situations in
which the passing by of a certain time is itself part of the plan (having
planted a tree, you have to give it some time to grow before you can expect
to be able to bring in the first fruits that grew on it).
2) A substantial uncertainty is introduced into each project that
is subject to this sort of time structure. It comes from the multiplication
of possible developments that might take place concurrently. Note that this
is not specific to idle times during the project. (There is no difference
between a garden that transforms into a wilderness because you're just
waiting to see what happens, and one that you leave to itself because you
have other and more important things to do.) It is not only that these
developments may take place and introduce surprising new facts - since the
duration in question cannot be known in advance, it is also often difficult
to estimate how many of these intermediate developments can occur, and what
their impact will be.
And there are other sources of uncertainty, of course: the outcome of
steps (actions) that are taken during the course of a project is not always
completely controllable; one might also make mistakes, both in the
assessment of the situation and in the execution of the steps which make up
the project.
The uncertainty that springs from the latter sort of sources results from
an imperfection in the agent's cognitive capacities, which may still leave
room for improvement; however, if it is the impact of concurrent
developments or other uncontrollable events that makes the actual course and
the outcome of a project uncertain, then the uncertainty may well be an
inevitable ingredient in all projects.
3) The last point needs closer examination. Arguably, since we all
are not perfect and do make mistakes in judging the situation and in
performing the steps in our projects (or have bad timing etc.), all our
projects include necessarily an element of chance. If this were the only
source of uncertainty, however, then that element of chance would be nothing
but a result of our imperfection, and it could be imagined that, at least for
certain projects (say, routine projects under safe conditions), and perhaps
with a certain training given to the participating agents, this uncertainty
could be reduced to a negligible minimum. Actually, there is a very common
paradigm for exactly this: automation, that is, the use of programmable
machines for executing pre-defined sequences of steps. Given that they operate
in environments stable enough not to endanger their functioning, they carry
out tasks very reliably.
The sort of tasks that can be carried out by machines resembles in some
respects the projects under discussion here. This applies even more so if
they include elements of error-correction and self-programming, which enables
them, to a certain degree, to react to deviations from the program. Still,
in general the outline of the sequence of steps is designed by humans,
not by the machines, and this is also where the purposiveness is imported.
Nevertheless, if we assume that the developments sketched in the two
previous paragraphs converge (i.e., on the one hand, the introduction of safe
conditions and training for agents, which reduces imperfection in them and
thus reduces uncertainty; and on the other hand, the development of self-
correcting and self-controlling machines, which may at some point in the
future be able to autonomously plan the sequences of their tasks themselves,
given some general goals and guidelines, and thus resemble human agents and
their projects), then we may think of uncertainties introduced by
imperfection in cognition and execution as reducible and perhaps negligible
in future times. However, as I pointed out at the end of section 2), there
is another sort of uncertainty that seems more constitutive for the specific
human projects under discussion.
The difference is that the latter sort of uncertainty springs from
steps with uncontrollable outcome that are taken in a project - sometimes due
to lack of more controllable alternatives, sometimes deliberately in spite
of, or perhaps because of, the risk involved. Similarly, the uncertainty may
be the result of the fact that the course of the project includes periods
that allow for concurrent developments that could have an impact on the
goals and possibilities that make up the project - and that may again be
something unavoidable or something that the agent considers as a bet he
wants to make. There is no equivalent here to the possibility of correction
as in the cases of uncertainty described above.
(Of course there may be projects in which this particular type of
uncertainty plays no role - the agent may find a sequence of controllable
steps at his disposal, and thus be able to avoid it. But this applies surely
not to all possible projects, and very probably only to a very small portion
of those which are actually carried out by agents in our world.)
It would be an interesting question how important uncertainty of this
sort is for our ability to formulate and carry out projects. Is it
constitutive (i.e. would there be no projects if this sort of uncertainty
would not occur)? Could we imagine an ideal world where there is none of
this uncertainty and still people work out and execute something that we
could recognize as projects in the sense discussed here? Note that this is
not precluded just by the fact that this uncertainty is not part in all
projects (as remarked in the previous, parenthesized, paragraph).
4) Hopes and fears are emotions that can result from that sort of
uncertainty in one's projects.[1] The uncertainty discussed here is
uncertainty in advance about the project's success and the actual course
that it will take when carried out - not the feeling of being
uncertain, or undecided, about what to do in a given situation. Hoping that
certain events will take place and that projects will have a certain desired
outcome implies that there is such an uncertainty (if one were certain of a
given outcome, one could still be looking forward to it, but this would not
be the specific emotion of hope). Similarly, fearing certain unfavourable
outcomes requires that these outcomes are thought to be likely, or at least
possible. Even if one knew for sure that a certain undesired event will
occur, one may still fear the moment when this happens. But plainly this
would not be fear because of an uncertainty. On the other hand, if it would
be regarded as impossible to occur, then if fear was felt it would be
certainly not fearing this event. (Consider: 'I am already at the station
and it is practically impossible to miss the train now. Still I'm afraid I
will not make it.' - This is irrational; if this sort of anxiety were felt
by someone, we would suspect some pathological constellation of his
subconscious and think that it is only overtly, and probably misleadingly,
about the train.)
Emotions in general have a structure that includes an element of belief
(emotions are about something that, crucially, one has to believe to
be the case) and an element of valuation (one must think that what the
emotion is about has a certain positive or negative value for oneself).[2]
Hopes and fears that are generated by uncertainty in projects, in the sense
described above, seem to share the element of belief, and to differ mainly
in the dimension of valuation: hoping means to assign positive values to
possible future situations during the course of the project, whereas fears
involve putting negative values on them. Their magnitude increases with the
significance that the project is seen to have (it is all the higher the
larger or more important the projects in question are for the agent), and
probably also with the importance of the steps themselves - if failure to
perform a given move successfully would be fatal for a project, its
significance will be generally much higher than that of moves that allow
for a 'Plan B', or that of such moves which might be tried again.
Let us turn to the element of belief mentioned above. The beliefs in
question here are about (possible) future situations. They are identical
with those that the agent forms to plot her moves in the project. For some
steps which he considers an agent will take the outcome as relatively
certain, and base a good deal of her plans on these assumptions. The outcomes
of other steps are uncertain, and (as pointed out above), sometimes it is
even uncertain which events may happen concurrently that affect the project -
the concurrency being due to idle times or waiting periods that delay the
progress of the project while developments in the surrounding world go on.
Having these possibilities in view generates hopes and fears (depending on
whether they affect the project in positive or negative directions) - but
this is not something that an agent can possibly avoid. Not considering the
possibilities at all would severely limit the capacity to form projects,
or would at any rate block the imaginative access to a high number of
possible courses that it would be advisable to consider. Considering them
but regarding them (incorrectly) as more certain than they are would amount to
delusion, and though it would eliminate the emotionality (and thus probably
remove unpleasant feelings, at least in the case of fears, and in that of
unfulfilled hopes), it would severely affect the success rate of projects in
general.
It should be concluded that minimally the hopes and fears that result
from the discussed type of uncertainty are an inevitable ingredient in lives
that are structured by projects. If there is any motivational import from
these projects, then it will be taken up by the valuations that partly
constitute hopes and fears concerning intermediate situations in the course
of the project. Short of reducing that motivational import, then, there is
no way to eliminate these emotions without unreasonably limiting the
capacity to form hypothetical beliefs, which are necessary to devise and
carry out projects at all.
__
[1] The discussion here does not cover all uses of 'hope' and
'fear'. For a helpful survey see Aaron Ben Ze'ev, The Subtlety of
Emotions, Cambridge: MIT Press 2000, esp. 473-489.
[2] See Robert Nozick, The Examined Life. Philosophical
Meditations, New York: Touchstone 1989, esp. 87-95, and the
bibliographical hints given there.
