Communications of the ACM

Communications of the ACM

Practical Programmer: On Personal Technical Obsolescence

By Robert L. Glass
Communications of the ACM, July 2000, Vol. 43 No. 7, Pages 15-17
10.1145/341852.341872
Comments

"Bob, there's something important we want to tell you. On the subject of CASE tools, you're out of date."
—Attendees at a seminar in 1988, after seeking me out for a private talk.

I am an old computing fogy. I've been in the software field for close to 45 years, now. I've seen the computing world move from octal to Java source code, from no operating system at all to operating system wars, from rudimentary tools to bodacious toolsets. I've seen exciting new technologies come ... and, sometimes, go.

There are lots of us old fogies in the field—managers, consultants, gurus, professors—who haven't written a line of production code in over a decade (or, perhaps, never). Do we really know enough to be spokespeople, even role models, for the field?

It's a fair question. It may be an embarrassing question, but it's a fair one. It's one I've personally wrestled with for over a decade (note this column's opening quotation). I suspect it's a question that almost any senior person in the field is wrestling with. It's a wrestling match held in secret, of course—our very livelihood and professional self-belief rests on the outcome of this wrestling match.

My quick answer to this fair question, as you might imagine, is "yes." I do still know enough to be a spokesperson for the field (otherwise, how could I justify writing this column?) I want to say a little more about my quick answer, about the fear underlying the question, and about what I have chosen regarding what to do about all of it. Another title for this column might be "Fear of obsolescence. And in a field as fast-moving as this one, it's a very real—and very important—fear. I suspect some of you reading this may share that fear.

The first thing I want to discuss is what I believe are the parameters for keeping up with our field. I believe there are two important information states we must keep up with—the state of the art, and the state of the practice.

The state of the art is typically described in the academic literature and textbooks of the field. This state is about academically perceived "shoulds"—it describes the beliefset of those with time to study the field on the ways in which people should build software. Interestingly, it is a fairly easy state to keep up with. Everything known about the state of the art is available to all of us in the published literature of the field. It may require some degree of intelligence—and occasionally, brilliance—to read that material, and (perhaps all too often) it also requires knowledge of what has been previously published, but there is no hiding the state of the art. The only problem (and this one is relatively minor) is that the publication lag time of state of the art material means what you are reading is a couple (or more) years out of date with respect to the most recent research findings. But since everyone except the involved researchers is in the same boat, this is not much of a problem.

---

There are lots of us old fogies in the field—managers, consultants, professors—who haven't written a line of production code in over a decade. Do we really know enough to be spokespeople, even role models, for the field?

---

The state of the practice is another matter entirely. This state is about what is actually happening in the field; it is the body of knowledge of all those who are software practitioners. Distressingly, it is a very difficult state to keep up with. Most practitioners are only familiar with the world of the enterprise(s) immediately around them. But different enterprises may be at very different places in their state of the practice. Popular computing press publications, which should help us with these kinds of questions, are very little help, since they are more often about some consultant, guru, or vendor's view of what the state of the practice should be (or what they wish it would be) rather than what it actually is. Thus most practitioners only have a narrow and distorted view of the state of the practice, and most academics have no meaningful view at all.

Is the lack of an understanding of the state of the practice a problem? My answer is a resounding "yes" for a couple of reasons. For one, without an understanding of the state of the practice, all of those "shoulds" that academics and consultants and gurus are pushing at us may be totally irrelevant. They may be irrelevant because they are things practice is already taking care of (thank you very much!), or they may be things that are of no benefit to practice at all.

Also, there are occasions in which the state of the practice actually leads the state of the art. I have written on this subject elsewhere [1, 2], so I won't dwell on it here except to note that practice in other disciplines has often led to the development of theory. There is every reason to believe that occasionally practice leads theory in the computing field. Successful software design happens even though design theory lags and flails. Successful software maintenance happens even though theory eschews the subject almost entirely. ERP systems represent the generalization of an entire and complex set of application domains, even though theory has not pursued and appears to be disinterested or uninformed on the subject.

As a specific case in point, consider the academic world's deep-seated belief in formal methods for building software, in particular formal specifications for representing requirements. The state of the requirements practice has moved, over the last couple of decades in which academe has been pursuing its mathematical approaches, from a belief in the need for a fixed and rigid collection of requirements to the need for a collection of fluid ones whose change is managed. That evolution has not been reflected in the writings of those who believe in formal specifications. Little has been said about the modifiability or maintainability of formal specifications in the face of managed change, as if the academic world is not aware that the underlying needs of the field have changed.

But that is something of an aside. The important point here is this: it is not enough in our field to understand the state of the art—one must understand the state of the practice as well.

Now, having said this, why is my personal answer to the question of still having sufficient technical knowledge "yes"?

1. I read the practical subset of the academic literature on a regular basis. I may skip some articles that don't interest me, and I may skim some that do, but I make an attempt to keep up with at least that part of the state of the art relevant to what I do.

2. I pursue the state of the practice on an ongoing basis. I do surveys of practitioner opinions and facts about how software is built. I read those portions of the popular computing press that present at least some semblance of reality (Communications, IEEE Software, InformationWeek, and Software Development are particularly good examples). I attend a smattering of practitioner-focused conferences. I try to stay in touch with industry practitioners through my newsletter, the Software Practitioner.

3. I strongly believe that, in contrast with the field of computing hardware, the field of building software has been relatively stable. There may be new toolsets and methodologies and process definitions, but if you look in depth at most of them, they are variations on a theme that has existed since the origins of the field 40-plus years ago. What is there in the SEI's CMM, for example, that is radically different from what we knew about building software a few decades ago?

Still, there are times when the foundations of my beliefset are shaken, such as when those seminar attendees quoted at the beginning of this column approached me. My response to their concern was to quickly immerse myself in the literature and seminar world of CASE tools, to absorb what I might have missed (as it turned out, given that CASE tools have fallen into some disrepute, I believe neither I nor my critics fully understood at the time what the new world emerging with the advent of CASE tools would bring).

More recently, I read a book on Enterprise Application Integration, which is a conceptual topic I grasp reasonably well, but whose implementation via CORBA, DCOM, Javabeans, DCE, ODBC, and OLE I could barely hold on to with slippery fingers. There will come a time, I realize, when I am no longer able to keep abreast of the states of the art and practice. And I will know I have reached that point because I have just read or heard something about one or both of those states that I am unable to follow, no matter how hard I apply my own personal understanding based on having been there and done that, or studied about it.

That point in time frightens me. Technical obsolescence is not a pretty sight. My greatest fear? That someone else will have to tell me. Like those seminar attendees did.

But whenever the time comes, it is my personal goal to withdraw—gracefully, I hope—from the field. I'll tell you when it happens ... or, perhaps, you'll tell me!

Do you have a plan for the eventual realization of your own personal, technical, obsolescence?

Back to Top

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.

---

No entries found