There is no doubt that all those creative milestones in software engineering history described in my two previous columns (March and August), things like high-order programming languages, operating systems, and modular programming, were truly creative. But there is an interesting question that must be addressed: exactly whose creativity are we talking about?
My primary concern as a practical programmer is about creativity in software engineering. I am most concerned with all the issues surrounding helping those who build software do a better—and more creative—job. But were all those milestones really supportive of that?
This is not only an important and interesting question, but it is one that had, a few decades ago, quite a bit of political stigma attached to it. But before I explain the stigma attached to these milestones, let me address the question itself.
My first answer to the question would be "Of course, these milestones were all creativity enhancers for software engineers," and I suspect that might be your automatic answer as well. After all, didn’t high-order languages, various methodologies, and software tools add monumentally to our ability to do our jobs?
On deeper thought you might begin to feel some doubt, as I did. Yes, software engineers were helped significantly by all these advancements. But did they help improve our creativity?
Before I deal with that question, I need to say where the primary creative act occurred. The obvious creativity in these milestones occurred in the minds of those who invented the milestones themselves. Think of the first person who invented a high-order language (HOL), and its necessary tool supplement, the compiler. Conceiving of HOL+compiler required seeing the "computer" in a whole new light, the light of symbol manipulator. In fact, it was about this time that the term "computer" became rather obsolete for our field, since machine usage was no longer limited to doing arithmetic on numbers, but was extended to doing complex logical manipulation of non-numeric symbols. HOL+compiler was a breakthrough—a silver bullet—on an astonishing number of levels.
But, once again, was it an act that enhanced the creative abilities of software engineers? My answer, after some further reflection, remains "yes." Given the ease with which a program can be written in a HOL as opposed to assembly language, the programmer was freed from machine-specific details and allowed to apply his mind exclusively to the problem being solved. And if that isn’t a creativity enhancer, I don’t know what is. Granted, the kind of creativity I am referring to here is different from that of the original creator of the concept.
Why would managers want to deskill their workers? In order to make it easier to control their performance, and thus to control the products they produced.
Now, those original "silver bullet" milestones were almost all clearly software engineering creativity enhancers, I would assert, if we use the same logic I used for HOL+compiler. Operating systems allowed the software engineer to concentrate on the problem instead of the machine’s architecture. Modular programming allowed the software engineer to work with encapsulated ideas, rather than ideas that spread freely (and sometimes randomly) across the problem/solution space.
It’s when we get to the subject of methodologies that the creativity argument begins to unravel. Is it more creative to work within a methodology like the structured approaches, or object-orientation, or are those methodologies simply a framework within which the programmer is constrained from doing things wrong, rather than helped toward being more creative? It’s possible to argue either side of that argument, I would contend, but to be honest my heart is less in arguing the "pro" side of this one than it was in arguing the "pro" side of HOL+compiler. I would assert what management had in mind in supporting the use of methodologies, both then and now, is imposing more control on the programming process. And, put that way, methodologies are not really about creativity at all.
There came a time, back in the late 1970s, when the issue of the benefits of software engineering milestones became the subject of some fairly radicalized discussions. Two authors took the position that all those software engineering milestones I’ve presented here were largely nothing more than a management plot, a plot not designed to make their workers more creative but rather to "deskill" them. Why would managers want to deskill their workers? In order to make it easier to control their performance, and thus to control the products they produced.
The two authors who strode forward on the computing scene at this time to mix the notion of political system and the notion of computing system were:
- Philip Kraft, a sociologist who viewed computing from a largely labor-management point of view. "Quite frankly," he says in the cited book, "I have become a partisan on the side of the programmer" [2].
- Joan Greenbaum, a former programmer who explored a radical view of social systems [1].
And the idea they presented in their two books was that all those milestones mentioned previously, especially the methodology ones, were intended to "routinize" the work of programmers: to "deskill" them.
How did their argument go? First of all, both authors based their books on research that involved interviewing programmers and their managers from the point of view of what was happening in the software world. Kraft saw, emerging from those interviews, a number of technical trends of the time that he interpreted to be meant specifically by management to lead to deskilling: structured programming, modularization and "canned programs," and chief programmer teams (CPTs, an organizational approach likened by some to the chief surgeon approach to managing a surgical team). In each case, Kraft felt these concepts, instead of leading to increased productivity (which nearly everyone in the field saw them producing), would lead to more management control of the programming process (structured programming by limiting the number of logic structures programmers could use, for example, modularity by maximizing the amount of pre-built code that could be used instead of new programming, and CPT because he saw it as "the most structured, hierarchialized, and status-bound [organizational approach] of any in the industrial world").
It is interesting to note that Kraft also saw the locked computer room (programmers of that era were not allowed to run computers; professional operators did) as yet another attempt by management to deskill, in this case by separating "head" and "hand" work. Given the contemporary environment of computers everywhere, if the closed computer room was really an attempt by management to exert further control, it was certainly an abysmal failure.
Kraft admitted, in passing, that the creators of these productivity enhancement approaches did not intend them to be deskilling, but he did not let that alleviate his concern.
Greenbaum’s book [1], published two years after Kraft’s, certainly picked up on Kraft’s view of structured programming, but apparently not his other concerns like modularity and the CPT. However, she was equally convinced that the so-called productivity improvements were really management plans to exert more control over their programmers, "in the name of efficiency" as her book title put it.
Not only did Kraft and Greenbaum see a management plot to deskill, they were surprised to find that, although programmers grumbled about management’s efforts, they made no attempt to resist or oppose them. Kraft said, for example, that he was "astounded by how routinely…programmers accepted their manager’s point of view, even though it came nowhere close to accurately describing the programmer’s real situation."
Both authors noted the trend away from fun in the programming process, toward a much more management-controlled form of work, a trend they said emerged as a pattern from their interviews with programmers. Greenbaum noted that "back in the 1960s, the people came from rebel stock: they were bright, creative…pioneers. Today they are a new breed, technically knowledgeable but more plodding." Kraft said much the same thing: "Barely a generation after its inception, programming is no longer the complex work of creative…people. Instead, divided and routinized, it has become mass production work." (Note that a concern for creativity keeps showing up here. Certainly Kraft and Greenbaum saw a role for creativity in software work.)
With the benefit of hindsight, of course, we can now see that most of what Kraft and Greenbaum foresaw would turn out to be untrue:
- That "centerpiece of management efforts to deskill programmers," structured programming, has largely disappeared at least conceptually from the landscape, to be replaced by object-oriented programming, which no one is claiming to be deskilling.
- "Almost certainly, the process of work fragmentation and programmer deskilling will continue and intensify" is wrong in today’s world of increasingly complex software systems.
- "Maintenance in particular can be more quickly defined and controlled by bureaucratic forms of management" was wrong then and, in a world where maintenance remains untamed, continues to be wrong.
In spite of all that, it must be acknowledged that Kraft and Greenbaum raised some interesting and important concerns approximately three decades ago. Any attempts to deskill programmers would certainly be counterproductive (and counter-creative) to the world of software as we know it (although I think none of us would put it beyond the realm of possibility that managers would consider such a ploy). But their fundamental notion, that all those creative advancements in the field of software engineering were really deskilling anti-creativity acts instead, can be disposed of fairly rapidly, simply by considering how complex the task of building software remains today.
Any attempts to deskill programmers would certainly be counterproductive (and counter-creative) to the world of software as we know it.
The political stigma Kraft and Greenbaum raised is, however, worth remembering. If management ever does plot to deskill the programming process, creative technologists everywhere must be ready to respond.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment