hopper, 1993 [5.2.3, abstract, overview, toc, switchboard, references]

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.
© Mary E. Hopper | MEHopper@TheWorld.com [posted 12/04/93 | revised 04/12/13]