.I. SYSTEMS SOFTWARE 219 1994; 25:219-222

Editor’s Corner A Tabulation of Topics where Software Practice Leads Software Theory

Robert L. Glass

I’ve been saying for several years now that, in a new discipline, sometimes practice leads theory. I’ve said it in print (Editor’s Corner, Journal of Systems and Sofmare, July 1989 and May 19901, and I’ve also said it in person before lots of audiences. Most of the audiences, be they practitioner or academic, listen with rapt attention and sometimes furrowed brows, as if “this is all very interesting, but do I really want to believe this nonsense”?

But in front of one audience, a particularly rapt- and-furrowed listener finally challenged me on the subject. “OK,” he said, “that’s an interesting theory, but get specific. Where in computing and software does practice lead theory?” That’s a fair question, of course. Now it was my turn for a bit of raptness and furrow. It’s all well and good to express a theory about theory versus practice, but could I make it become real in a practical sense?! (Do I detect a bit of something similar to recursion here?)

I’m not a terribly creative thinker standing on my feet in front of an audience. All that adrenalin that surges through my body parts to get me into a high-energy mode for speaking seems to sap the brain power needed to do new things with a few dozen or hundred people watching. On the occasion where the listener challenged me, I mumbled some things about creative design and graphical user in- terfaces being areas where practice led theory, but then I hastily looked at my watch, harrumphed about being behind schedule, and went on with my pre- pared speaking materials.

Back in the safety of my own office, after the adrenalin had calmed from a waterfall to a trickle, I began thinking about that question some more.

This editorial was reprinted with permission from The SoJwure Practitioner, P.O. Box 213, State College, PA 16804.

Where, indeed, does practice still lead theory? Here are some of the thoughts I had.

Software Design

People have been doing software design now for four or more decades. Many of those designs have been successful, some phenomenally so. Those de- signs that have succeeded have been the product of creative minds focusing on fairly complex problems; remember the Fred Brooks quotes about “software being the most complex task mankind has ever un- dertaken?” So there’s plenty of evidence that the practice of design is a thriving enterprise.

What about the theory of design? Look at any textbook on software design, and tell me what you see there. I’ll bet it’s a bunch of stuff on methodol- ogy and a bunch of stuff on representation. Follow these methodological steps, the textbook implies, and you’ll have some thoughts worth drawing with this representation. Well, not good enough. There’s many a creative step twixt the methodology and the representation, and what’s in the textbook leaves all of that out.

Plus think about this: When did methodologies and representations arise in the software world? How about the 197Os? And when did practice start designing real production software? How about the 19.50s? No matter what sword you use to slice it-a historic one or a contemporary one-practice has led and continues to lead theory here.

However, I think it is important to admit that theory is playing a good game of catch-up on this topic. The research into cognitive design by Bill Curtis and coworkers, and Elliot Soloway and his, brought theory well into a position to catch up with practice on creative design. But that happened in the 198Os, and is still not well acknowledged in the textbooks and theory work of our time. For a little

0 Elsevier Science Inc. 655 Avenue of the Americas, New York, NY 10010 0164-1212/94/$7.00

220 J. SYSTEMS SOFTWARE 1994; 25:219-222

Editor’s Corner

while, at least, I would assert that the practice of software design still leads its theory.

Software Maintenance

The first job I got in industry, over 40 years ago now, was one doing software maintenance. I wasn’t very good at it then, but after getting lucky-1 was given software designed by some pretty superb software developers to maintain-I made significant strides in my maintenance maturity within a few years. What did computer science and software engineer- ing have to say that would help me do that software maintenance at the time? Absolutely nothing! In fact, there was no computer science or software engineering then, in an academic/theoretic sense. Those disciplines first graced the halls of ivy over 10 years later.

But is all of that ancient history still relevant today? I say that it is, and for a particularly sad reason. Until very recently, the theory world of software actually disdained the subject of mainte- nance. It wasn’t just behind practice, it was refusing to try to catch up! The software literature displayed an amazing paucity when it came to theoretic contri- butions to maintenance. I recall one academic mak- ing a presentation at a software conference whose content was clearly behind, and could have benefited from an understanding of, the state of the practice! (Editor’s Corner, Journal of Systems and Software, May 1994)

That is beginning to change, now. But it is still sad to note that the places where the change is happen- ing-the University of Durham in England, the Uni- versity of West Florida, Arizona State, DePaul, and a few others-can be counted on the fingers of one, or perhaps barely two, hands. There is still very little solid interest in software maintenance in the world of theory.

Now there is a very well understood theoretic approach that theory can use, in any discipline, to catch up with leading practice. It is called empirical studies, and it involves studying the best of practice in order to evolve theory. But software theorists have, to date, exhibited little interest in use of that very effective bootstrapping approach, and as a re- sult it is fair to say-as of the publication of this essay-that there is little evidence that theory is making much progress at all in catching up with the world of software maintenance practice.

User Interfaces

Here is a nice example of an area where theory and practice are proceeding neck and neck, and there is

every reason to believe that theory is pulling ahead. Still, it is an interesting example of what happens during the phase when theory catches up with prac- tice.

The pioneering work in user interface develop- ment, as any computer-crazed schoolchild knows by now, was done at Xerox PARC a couple of decades or so ago. Now how do we count that work? Was it theory work? (It was done in an industrial setting). Or was it practical? (It was done by theorists who, except for their industry identification, had all the trappings of academe). It seems to me fair to take the position that this pioneering work was a mixture of theory and practice.

What happened next? Much of the work made the transition into industry, where Apple made it into an industry standard and based most of its long-term economic success on continuing to use and further develop the Xerox PARC concepts. Theory develop- ment continues, of course, but it is probably fair to say that the great theoretical/practical leap forward that happened all those years ago has not been equalled to date in either theory or practice.

Programming in the Large

Pragmatic programming has always seemed like pro- gramming in the large. That is, every generation of practitioners has probably had the feeling that the software they were building was severely stretching their intellectual capabilities, and those of the hard- ware they were developing it on, to the absolute limit. And, of course, every generation of practition- ers has been trampled in the dust by the onrushing complexity of the problems tackled by the next gen- eration. I still find it difficult to believe-but I can’t refute the numbers-that software systems were 50 times larger, on average, in 1990 than they were in 1980 (Dekleva, 1991). That is a staggering commen- tary on the rate of change in the world of software practice.

In the meantime, what has been happening in the world of theory? In most places, theory development is still based on small studies of small projects. Practitioners make fun of that approach by calling it “toy projects.” But I prefer to give it a little more dignity by calling it “research in the small.” There are a few counterexamples of people and places doing research in the large-the work of Vie Basili at the University of Maryland, Chris Kemerer at the Massachusetts Institute of Technology, and a few people at the Software Engineering Institute come to mind-but, for the most part, theorists are stuck trying to extrapolate findings from research in the

Editor’s Corner

small to programming in the large. And, as most people in software engineering have known since the term sofiware engineeting was invented over a quar- ter of a century ago, it just won’t work.

Now here, of course, theory has a severe problem. It costs a lot of money to do research in the large. And most software researchers haven’t developed access to the kind of money needed. So it is easy to understand why the world of theory has not grown to match the needs of practice.

But at the same time, it is not unknown for some insensitive computing theorists to poke fun at prac- tice for being stuck using old technologies and con- cepts. I sometimes wonder what would happen if computing practitioners poked the same kind of fun at theory for doing the same thing?! I don’t imagine that progress in the field would be helped by that kind of social interplay. But still, isn’t there some- thing about “sauce for the gander”?

It is time for the world of software theory to graduate to something that Vie Basili calls “full-pro- fessor research.” What does he mean by that? My interpretation is this: new professors tend to do research that involves making in-depth studies of disciplinary minutiae. That kind of work is consistent with what they did in their graduate studies, and is necessary to get them tenure. But the time comes when someone-preferably those who have leaped the tenure hurdle-ought to do more in-breadth examination of the key issues of the discipline. Full professors, and others senior in the field, are in an ideal position to do that.

Who is doing full-professor research? In addition to those named above, it is interesting to examine the work of Mary Shaw of Carnegie-Mellon Univer- sity, who has studied the origins and evolution of the various engineering disciplines for an understanding of the evolution of software engineering. There is much, she has observed, to be gained in understand- ing our own field through that approach.

With a stronger commitment toward research in the large and/or full-professor research, and with a large dose of funding thrown in to help make it happen, it is possible to get the world of research in the large moving faster. Perhaps, with enough help, it can even catch up with the practice of program- ming in the large.

yodeling and Simulation

If you have ever worked on a large real-time soft- ware project, then you know how much a part of the development of that kind of software modeling and

J. SYSTEMS SOFTWARE 221 1994; 25219-222

simulation are. Models are developed and simula- tions run in order to

1.

2.

3.

4.

5.

analyze the concept of the system before starting to build it; run design studies to check the viability of design approaches; allow the execution of target computer software on a host computer with a different instruction set (because the target computer is not yet avail- able, or not capable of supporting debugging); substitute for the real test environment during early environmental testing; produce appro~mate test oracles for checking the test results produced by the as-built system dur- ing system test.

That is a lot of modeling and simulation. The tech- nology, you can see here, is an essential part of the real-time software practitioner’s world.

What is the world of theory doing here? My own observation is, not much. When I judge by the number of courses that theorists introduce into their curriculum, for example, I see virtually nothing on this subject. And yet, in practice, instruction-level and environment simulators and all the others we talked about above have been an absolutely essen- tial part of doing business for decades.

Modeling and simulation are, of course, heavily used in some fringe areas of computer science the- ory, especially those having to do with manufactur- ing applications. But that is far from the mainstream of computing theory. When they appear in an aca- demic discipline, in fact, modeling and simulation are usually taught in some other college, not the one housing computer science or even software engi- neering.

This is what I call a “gap” subject in contrasting theory and practice: it is a subject where practice has a presence and theory does not, thus identifying a gap in the underlying theory. And when there are gaps in the theory, it takes an awful lot of catch-up for theory to even begin to approach practice.

Metrics

This is a field where bifurcation has occurred. What theory is doing with respect to measurement of software work and what practice is doing are on two different planes, planes that are shifting in different directions.

Take a look, for example, at the encyclopedic theory work on metrics by Zuse and compare it with the practical books by Grady. Or contrast the com- plexity metrics work done by Halstead and McCabe

222 J. SYSTEMS SOFTWARE 1994; 25:219-222

Editor’s Corner

with the quality metrics work funded at the Rome Air Development Center (and documented in many studies filed with the National Technical Informa- tion Service). It is almost as if the two areas have given up communicating with each other.

As editor of the Journal of Systems and Software, I had the good fortune to read the comments an anonymous theorist reviewer passed on to a theorist author of a paper on metrics. The message was basically this: Why are you bothering to propose unverified additional theoretic metrics when (1) the theory world is already full of other unverified met- rics, and (2) the practice world has given up on all of this unevaluated theory and is rapidly moving on in its own directions? My personal bias is that this reviewer/theorist (who was unwilling to be identi- fied because his theoretic colleagues might “crucify him”) is one of the few who has grasped what is happening in software metrics.

There is, of course, a bit of theory/practice over- lap. Many enterprises doing software maintenance use the commercially available CASE tools built to calculate the various theoretic metrics such as Hal- stead and McCabe, and say that the identification of complex code segments that they obtain in that way is very helpful, especially in planning reengineering activities. But there is another strange faction in the metrics world. There are many, both theorists and

practitioners, who have explored the various com- plexity metrics and found them to be dubious when theoretic justification is attempted and of little value in a practical setting.

Perhaps the best summation for the topic of met- rics is that here is a field where there is much turbulence in the relationship between theory and practice. But it is fair, I, think, to say that practice is very slowly beginning to evolve some practical, use- ful metrics, and that theory is still trying to decide whether its own work has merit at all. This is an area, I would assert, poised for explosive growth once these early difficulties can be sorted out.

There, then, is my response to my rapt and fur- rowed questioner. At least in these areas-software design, software maintenance, user interfaces, pro- gramming in the large, modeling and simulation, and metrics-software practice leads software theory. This is the response I wish I had been able to make on the spot during my lecture. But perhaps, if that listener has happened to run across this essay, he’ll recognize his question-and be glad for this belated answer!

REFERENCE

Dekleva, Findings of a survey by Sasa Dekleva, Software Maintenance News February (1991).