Software Conflict 2.0: The Art and Science of Software Engineering by Robert L. Glass

Author:Robert L. Glass
Language: eng
Format: epub
Publisher: developer.* Books
Published: 2006-03-09T20:00:00+00:00

A New Way of Looking at Software Productivity

How can we improve software productivity by orders of magnitude?

That was a question the Department of Defense asked a few years ago. It's a question all of us in the computing profession have asked ourselves over the years, for that matter.

There tend to be two kinds of people who respond to that question. One kind, those who think they know how we can do software 10 or 100 times better, propose to do it with lots of research money and methodology breakthroughs. “Give us X thousand dollars,” these people say, “and we will show you how to do automatic code generation from problems posed by experts on cocktail napkins.”

The other kind of persons, those who think that no one knows how to do software 10 or 100 times better, wring their hands and say things like “Alas, don't throw any more money after that problem, it appears to be unsolvable.”

Like so many other polarized life situations, hardly anyone is taking a middle ground between these two extremes. Is there any combination of currently known techniques which can lead to significant improvement in software productivity? Only a few people are exploring that question, let alone tentatively offering a “yes” answer.

Of course, there are the methodology hucksters who promise those kinds of improvements from whatever they happen to be selling at the moment, usually a technique called something like “Structured Poobah.” It's been hard to discuss the matter rationally with those folks, because they're so busy selling that they haven't time to talk about the existence of any hard evidence to support their claims.

There is, however, some disquieting data on that subject. One set, visibly enough, is found on the cover of Barry Boehm's book, Software Engineering Economics. Boehm's data show that, when it comes to productivity, methodologies and languages and other technology approaches are down in the noise level of improvements.

A few years ago an article appeared in one of the professional journals which reported the results of exploring experimental research findings on the benefits of methodology improvements, such as the structured methodologies. The conclusion of the study was that no experiments existed which could shed any significant light on their benefits. That was kind of a downer!

At a more recent computing conference, researchers reported on one small experiment into one small area, the benefit of using structured versus unstructured code. In this experiment, the benefits were clear (that was the good news) but nominal (that was the bad news)—down around 5 percent.

At that rate, it would take quite a collection of methodologies to add up to an order of magnitude improvement. Looked at realistically, these data indicate that we may not get there from here that way.

But let's look at the cover of Boehm's book once again. There was one productivity factor which was head and shoulders above the rest. It was the quality of the people doing the software work. Perhaps here, in the sociology of the technology of the software field, is the answer to the DoD's question.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.