I see this workshop as a wonderful opportunity to further "map the terrain" of end user programming. Despite the good work that has already been done in this area, I find myself still groping around at times, unable to find my bearings when I think about the issue of end user programming. What I hope to get out of this workshop is a better map and a better set of tools with which to think about this problem.
I first started thinking about issues related to end user programming in the late 1970s, when I became interested in the issue of what was then being called, at least in some social science circles, the "deskilling" of programming. Programming in the 1940s and 50s had been seen as the province of highly educated male professionals (at least after they took the job away from those clever "Seven Sisters" grads, the ENIAC girls.) Suddenly, during the 1960s, ads started appearing in busses and subways, touting a 6-month course at ITT Tech that would make you into a computer programmer. What happened? A decade later, around 1978, when I first started nosing around in this area, I did some volunteer work at an agency whose mission was to place women in nontraditional work. They had targeted five occupations, and were having a hard time with four of them. The fifth, computer programming, was a piece of cake: women were having a comparatively easy time getting into this male dominated field. Why? I guessed that it wasn’t just that it was a high demand occupation, or that employers in this sector of the economy were particularly enlightened, but that it could also have to do with a change taking place in the occupation of computer programming. The history of women’s employment is filled with cases in which women gain access to jobs just at the moment that these jobs are being reorganized—usually in a way that makes them less secure, less respected, and lower paid.
I was a Doctoral student at the time, and my investigation of these questions led eventually to my dissertation research at Bank of Boston, where I looked at the question of whether programmers were being "deskilled." What I found, looking at applications programmers and analysts, was that from a purely technical point of view one might be able to make an argument that applications work was less skilled: applications programmers were either writing COBOL or using the 4GLs available in the mid-1980s. However, what I really found among applications programmers was a shift in skill requirements: coding may be less demanding, but they were required to know more about their (internal) customers, the bankers, and about banking. The IS people and the traditional banking people were beginning to converge somewhat, and some people who started in the systems area eventually learned enough about the work of bankers that they left systems and went into traditional areas of the bank, where they continued to do systems related work. Some bankers, too, got so interested in systems that they jumped over the organizational wall and joined the systems organization. Finally, there were small pockets of people (mostly women, in my experience) who came to act as informal middle-people between the bankers and the systems employees. They were the group that became the interpreters (translators, in Williams and Begg’s [1] phrase) between end users and programmers on given projects, because they had experience in both areas and were able to "speak the language" of both groups. PC’s had just established a beachhead on some desks at the bank, and because of the cumbersome nature of development projects, the enormous backlog of work in the systems area of the bank, and other factors, professionals on the "banking" side were starting to do their own computer analyses (typically with spreadsheets.) This was end user programming circa 1985 in Boston.
Here is some of the terrain that I would like to map:
What is programming? Nardi [2; page 7] has a wonderful Figure locating programmable systems in a two dimensional space. The X axis represents degrees of expressiveness, ranging from parameter setting/customization at the low end to traditional programming at the high end. The Y axis represents the extent to which there is interactive construction (I think I have this right.) Thus DOS/UNIX init files are low on both dimensions, while visual programming is high on both. I would like to see this scheme elaborated, especially the dimension that measures the extent of programming by the degree of expressiveness. When do we want to say that end users are programming, and when are they just customizing? Is there a bright line? If so, what is it? If not, how can we distinguish an end user who is programming from one who is just a "power user?" Do we want to make this distinction? Why? Do we care about programming per se, or just about enabling users to get as much power as they can from software without having to get help from programmers? Is there a "continuum of programmability," and if so, how would we describe the points along the continuum? Are expressiveness and interactivity the only two dimensions? Are there more?
What do users want? Nardi [2; page 5] also places computer users along a continuum: at one end, the user for whom the computer is merely a means to an end: "I didn’t have much time, so I did it the long way." At the other end, the user for whom programming—or at least thinking about programming—is an end in itself: "I would rather write programs to help me write programs than write programs." The first user wants the computer to be transparent—a lens through which to view what they are really interested in: their work. For the second user, the technology, and getting it to perform, is the point. Who is in between? Well, me, for one. Mostly for me computers are a tool, but I do take delight in an elegant interface, a new trick, or the fact that I can very easily correct my typing mistakes. When I am frustrated by usability problems I devoutly wish that the system were transparent, but when I discover that my Palm Pilot can do something cool, I’m genuinely pleased, even if that feature isn’t very useful to me in my daily life. So mostly I want to get my work done, but I’m happy to have some fun along the way.
What benefits users as employees? Looking at the question from a labor relations perspective, I also want to ask what arrangements give employees the greatest employment security, both helping them to retain their current job, or to become employed or re-employed when seeking a job. The old joke about spaghetti code being job security reminds us that things that are arcane and unusable do serve at least the function of preserving the job of the programmer. So, aside from having things that just let them get their jobs done, what is in the best interests of end users as employees? One answer, for me, is a work situation that allows them to develop skills that are transferable to desirable future jobs. Learning higher-order thinking and analysis skills seems to me to be the most important thing for long term employability in well-paying work. Specific technical skills, like VB, Java, HTML (and even, pre-Y2K, COBOL skills) are short term benefits when those skills are in high demand. They especially benefit entry level employees, like Business majors who are good with Excel, new architects who are experts with CAD, and planning students proficient with GIS. So I tend to emphasize learning what Frederick Brooks [3] calls the "essential," rather than the "accidental" things about programming: learning how to think, not how to code. From another perspective, though, having a "richer" job can mean more responsibility and more work, but not more pay. This often happens, in fact, in workplaces during this era of downsizing and "lean and mean." In this case, a shift to end user programming may not be all for the good.
"We shape our tools, and afterward they shape us." I assume that end user programming is good from the point of view of human development, because the more active we can be in controlling our world, the more engaged, optimistic, and creative we are likely to be. But just to be contrary, and specifically to undermine the excellent distinction Brooks makes, referred to above, I’ll put forward the proposition that perhaps we can’t separate the essential from the accidental aspects of programming. (This is another spin on my first question, what is programming?) The conventional model of software development says that first we do analysis and then we do coding. But my experience at Bank of Boston made me think that analysis and coding may be, at best, a nested series of Russian dolls. When I asked one interviewee at the bank, "When do you stop doing analysis and start coding," her reaction told me that it was as if someone had asked me, about my academic work, "When do you stop thinking and start writing?" My answer is that for me thinking and writing are so intertwined that I can’t separate them. I may think first, but in the act of writing what I have thought about, I also transform it. The Sapir-Whorf hypothesis suggests that language is not just the thing we use to name our world, but that the language we use actually shapes our perception of our world. This means that the Navajo and the Australian actually see the world differently, rather than just speaking about it in different words. Might computer languages be similar to natural languages in this respect? Do we see the world differently through Fortran than through Java? If so, what are the implications for the tools we create for end user programmers, and how they will experience the world with these new tools?
And what about Participatory Design? Howie Goodell says that end user programming is the answer to Participatory Design, which seeks to give end users a central role in the systems design process. I’m not yet convinced, but I’m open to suggestion. I’d be interested to explore this terrain, too, in the workshop.
References
[1] Marian G. Williams and Vivienne Begg, 1993. "Translation between software developers and users." Communications of the ACM, Special Issue on Participatory Design. Vol.36, No. 6, pp 102-103.
[2] Bonnie A. Nardi. 1993. A Small Matter of Programming. Cambridge: MIT Press.
[3] Frederick P. Brooks, Jr. 1995. "No Silver Bullet—Essence and Accident in Software Engineering." Reprinted in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Reading, MA: Addison-Wesley.