5.2.3.2 Working Patterns and Motivation
The concept of human resources must include consideration of such things as
motivational characteristics and productivity under particular working
conditions to give a more complete picture of the factors which consistently
characterized the projects examined during this research. Many of the distinct
challenges related to human resources were due to the nature of the academic
communities in which the projects took place. This is clearly apparent in
the passage below (J. Rehwinkel, personal interview, June 22, 1992):
Hopper: Do you see there are time and seasons in the academic
environment when things get done more than others then? It's not the same
progress all year round?
Rehwinkel : Summer was the best time to work on the databases. I was back
here by myself in this office. It was quiet and nobody bothered me. In fact,
I didn't even have the lights on.
Hopper: Is work environment important then, to the progress of work?
Rehwinkel : To me it is. Summertime is when I can do a lot more work,
because there is lower pressure and there are no class deadlines.
No matter which type of development was being done, there were definite
and consistent conditions that surrounded the highly time consuming
and complex activity. There are a number of possible explanations for
why these patterns existed. One easy one is to attribute them to the
personalities of the developers. However, there was some evidence that
there were elements inherent in the nature of the development activity
that led to the number of related and frequently noted phenomena.
One pervasive suggestion was that the "developer's" patterns were
due to the complex and unpredictable nature of tasks. These patterns
appeared to be efficient ways to cope with complex development tasks,
because every time a developer would leave a task and come back to it,
they would have to spend time reconstructing a representation of the
task before they could move forward. It was common for developers to
both underestimate the time it would take them to complete a task,
and forget how long it took them once the task was complete.
(A. LaVin, personal interview, October 2, 1992)
LaVin: I shared an office during most of the project.
During the day, I also had many interruptions. It was my job to deal
with the students and help them with problems. They would drop by a
couple of times a day during the semester. If I had to sit down and
do some coding or write some documentation, it was often very difficult
to do during the day. If I've got to sit down and put my blinders on
to do something, I need some time to get into it. Once I'm there,
then I'm going to do it until it is done. Sometimes I would come in
on weekends and spend a whole afternoon working. We also wouldn't
realize how hard it would be to do a particular task, and so we would
underestimate the time it would take. I would think I could get a
module description done in 2 hours, and ten hours later I would have
had to dig through 8 books to figure out why a theory said something.
Or I would think, "I got it done in a week last time." I would forget
that I got it done in a week because I stayed awake the whole time.
It just doesn't sink in that it was a really horrible week!
This pattern may happened because developers perceived time as passing
more quickly when they developed. When they would estimate how long a
task would take, they would base their estimate upon the short period of
time they perceived it to take, rather than upon the time it had actually taken.
Developers also seemed to forget the details of the complex processes they would
go through. They remembered the overview of it, rather than all the little things
they forgot they had to do to accomplish the larger tasks.
Another critical attribute of developers patterns was the task involved state
that appeared to surround the development process. The patterns were not
characteristic of traditional time and effort devoted to employment,
and were sometimes beyond the fiscal resources available to the project
(P. Kinnicutt, personal interview, October 1, 1992).
Kinnicutt: Work on this project was cyclic. I was a Teaching Assistant
for a C programming course, and that involved times in the office to help students.
Hopper: Do you find any particular pattern in how long you work on development at a time?
Kinnicutt: For me, the task drives how much time I spend on a particular day.
I set aside some agenda I wanted to accomplish, and then did it from beginning to end.
I would work until I got it done. It could be 5 p.m., or it could be midnight.
One major explanation for the task oriented nature of the development process
was purely a function of the level of complexity inherent in the task. The task
involved character of developers during the development process could have also
been due to various sources of intrinsic motivation they felt towards the working
on the project. Evidence to support various degrees of task involvement from
intrinsic motivation were found through work patterns in every project
(E. Schlusselberg, personal interview, October 1, 1992).
Schlusselberg: My working patterns are based on what has to get done.
If something is not finished, that's all I can think of. The projects have deadlines.
And if I said it was going to get done, you can bet it's going to be done.
Even if I have to stay till 2:00, until 4:00, if I don't sleep. I am very
fortunate because the working schedule and conditions here are extremely flexible.
If you need to shut your door, you shut your door. If you need to come in at
3 o'clock in the morning, you come in at 3:00. The thing is that,
the administration has to really trust the people that are working for them.
Obviously, if I'm coming in at 3:00 in the morning, nobody knows that I'm here.
It's also hard to develop when you have many other "little things to do".
What I usually try to do when I'm building an application is to just focus
on the one project. You sit down, it takes you like a little time to get into it,
and then you go on a roll.
If it is the case that the patterns were not only the result of the cognitive
demands of the task, but also an internal motivation on the part of the developers,
there are widespread implications. One potentially complicated set of issues is
the amount of ownership that could be generated by developers who were deeply
involved in their task, and perhaps the product of the process. At this point
credit giving and respect factors come into play because of the effects of
appropriation and ownership are important whether learner or developer oriented.
In the following passage, Schlusselberg (personal interview, October 1, 1992)
confirms the importance of motivational issues, and elaborates on the ways in
which they can impact projects.
Schlusselberg: There are many things which affect the end product.
People are the most important thing. It really depends with whom your working,
and sometimes it boils down to personalities. If people are not happy working
together, it effects the project. It's important that people working together
respect each other's interests and see each other as professionals. Some people
think that because they were able to secure the funding that their ideas are worth
more. In the Center, although there are organizational hierarchies, we try not to
have them influence the way we work. So ideas are discussed. I also think that
implementation people are very important. If they are not there, the project does
not move. However, their contribution and influence is sometimes overlooked.
You must give credit to the person with the idea, particularly in a research environment.
I think that what sometimes happens in an academic setting where the hierarchy is
made up of faculty members, doctoral students, master degree students and
undergraduates, the top levels absorb a lot of the credit from the lower levels.
So when I work with students, I make sure that their work gets acknowledged.
I let them present their own work, which lets them take pride in what they do.
Some people can use the analogy of a book where the author and the publisher get
the credit. But I think movies are a better comparison where everybody who had
anything to do with the movie get their name listed in the credits.
The existence of these types of considerations within projects suggests
the possibility that the patterns that are observed go a great deal deeper
than just cognitive demands of the task. In particular, the extremely task
involved and intrinsically motivated nature of people who worked on courseware
may lead to a key rationale for learner constructed instruction as a powerful
educational tool.