Practical Programmer: Is Criticism of Computing Academe Inevitably Divisive?

I was talking to a computer science professor the other day, expressing some of the same opinions that I tend to share in this column—a belief in software practice and practitioners, a concern for some of the directions being taken in computing academe, and a particular concern for what I call the "communication chasm" that I see between practice and academe. The professor said that in expressing these beliefs I was being "divisive."

That bothered me. I gave quite a bit of thought to this criticism during the ensuing days. In expressing my beliefs, particularly in this column, am I indeed tending to divide the field? It’s certainly not what I intend. I believe there is a desperate need in the computing field for practitioners and academics to believe in each other and work together. But is my way of addressing my concern contributing to making that more difficult to accomplish?

In reviewing this criticism, I went back over the pieces of the conversation that had stimulated the professor’s rejoinder. I had just finished congratulating a symposium speaker on his discussion of software architecture, in a context where patterns had also been discussed, and I had said, "One of the most intriguing things about the architecture and patterns communities is they base their work on the findings of practice more than they do on the findings of theory." I meant this as a compliment to my academic brethren who are exploring architecture and patterns. I then said that I saw this practice-relevant research as a positive thing, a breaking away from what I consider the unhealthy tendency of computer science to adopt the viewpoint of its mathematical heritage that neither practice nor applications are worthy of academic interest.

That is when the professor told me I was being "divisive." Was I?

My reaction, upon some reflection, is that I was not. The professor didn’t like what I said, of course, but that didn’t surprise me. I believe the only way we can even attempt to overcome this communication chasm is for people on each side to express themselves frankly and openly. With that in mind, what might appear initially to be "divisive" is simply the first necessary step to chasm mending and bridge building. If those of us on either side of the chasm are unable to express our view of what is on the other side, there is little hope for resolution. A truism in the field of psychotherapy claims opening old psychological wounds is the only workable preliminary step to healing them. I believe the old wounds in the computing field are long overdue for exposure—and healing.

---

If those of us on either side of the chasm are unable to express our view of what is on the other side, there is little hope for resolution.

---

That thought process probably would have been the end of that, had it not been for a wonderful backward-looking article in IEEE Computer that arrived in my mailbox a couple of days later. Maurice Wilkes described "A Revisionist Account of Early Language Development," particularly the advent of, and conflict between, Fortran and Algol (and their respective adherents). In Wilkes’s discussion, the origins and ongoing history of that communication chasm all came flashing back to me.

He summed up the dilemma very graphically: "Although the builders of the early Algol compilers had some experience in computing, they were educators and research workers rather than serious computer users. To them, Fortran seemed crude and ugly. They deplored the blindness, as they saw it, of Fortran users, who did not immediately appreciate the superior merits of Algol. They refused to be impressed by Fortran’s success in a world where what mattered was obtaining numerical results with a minimum of trouble and delay.

"Unfortunately, this attitude was matched by—or perhaps was the cause of—a corresponding attitude on the part of many Fortran users … They had backed Fortran and felt they were the experts. They resented the idea that people calling themselves research workers should try to tell them anything. One commonly expressed view was that the few smart programmers who existed would be better employed in writing application programs than in doing research on new languages.

"… A direct and unfortunate result was that the world of programming language enthusiasts and practitioners split into two camps. In one camp were the pragmatists, with Fortran on their banner, and in the other camp, the intellectuals, with Algol in theirs. This split was to bedevil the programming world for many years.

"… The prejudice in computer science circles against Fortran was responsible for the failure to follow one obvious line of research. It should have been asked what it was about Fortran that users liked, and an attempt should have been made to design an improved language that they would like even more…"

I particularly resonate with Wilkes: "This split was to bedevil the programming world for many years." Wilkes’s "split," I would assert, is now the "chasm" I believe is still with us. It is this split that comes into play when I express what I would like to be seen as constructive criticism but someone hearing me takes as divisiveness. Computer scientists seem to see no divisiveness in their being able to say that Fortran was "crude" and "ugly," and that its adherents suffered from "blindness." It is almost as if, when the shoe is on the other foot and pragmatists criticize academe, academics cry "no fair." And that is not a healthy response to attempts to overcome chasms and splits that reside deep in our mutual past.

In that spirit, let me quickly review where I have taken this column in the roughly two years I’ve written it. I have

• Expressed my belief in software practice, and my concern for its relationship with academe, in my first column, "The Relationship Between Theory and Practice in Software Engineering," in which I focused on those areas where practice, I believe, leads theory.
• Spoken of the series of "date crisises" that are plaguing practice, where Y2K is only the beginning of the problem.
• Presented research findings that show "programmer stress" being one of the leading causes of software problems.
• Documented several attacks by theorists on the world of practice, in which (a) an academic talked about "desperate" practitioners being willing to utilize "any tool or notation" in order to overcome the "software crisis" he saw happening in the field; (b) another academic expressed his opinion that researcher-built tools are larger and more complex than application software; and (c) yet another academic stated as fact that a leading software company used inadequate techniques.
• Expressed my concern that Cobol is disdained by academics, and yet they have made no effort to understand the needs of the application domain for which it was defined (shades of Wilkes’s Fortran vs. Algol discussion).
• Given my view on software "runaway" projects, which are painfully frequent but provide only anecdotal, and not quantitative, support for the existence of a software crisis.
• Presented research findings that support the notion that software inspections are one of the most important tools at the software developer’s disposal.
• Given a hard-nosed analysis of a troubled software shop in which neither process nor people problems were at the heart of what has gone wrong.

I would like to believe that the sum of what I have said in "Practical Programmer," to date, is more consistent with bridge-building than it is with divisiveness. But I’m curious to know your reaction to my belief.

Back to Top