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

To Iris,

who helped me grow

I was cleaning the back of a little-used closet a few months ago and happened across a box of computer magazines from the late 1980's and early 1990's.

For one long summer back then, every magazine dealt with the same hot-button issue: which platform would win the GUI warsMotif or Open Look. The debates over the relative technical merits of these two systems were intense and detailed.

And, of course, completely pointless.

An older magazine, from the Paleolithic era of CP/M and the S-100 bus, had an advertisement for a new database product that would end the drudgery of coding forever. Reports and database queries could be made in plain English, and soon programmers wouldn't be needed at all.

Didn't happen.

Various other technical issues were also covered in a similar style, and followed a similar lifecycle: introduction, fevered hope, tremendous hype, lengthy and thoughtful debate, and ultimate abandonment as the Next Big Thing came on the radar.

And against that backdrop of new computer languages, new methodologies, new frameworks, and all the rest, the majority of all software projects were still late, over-budget, and under-featured. We were getting answers, but we were asking the wrong questions.

Clearly, advances in technology haven't helped us deliver decent software on time. And yet, magazine after magazine, and book after bookthen as well as nowcontinue to focus on the low-level technology.

Fortunately, we have authors like Bob Glass to keep the conversation at a higher level.

Bob's essays focus on the realities facing practitioners. There are no angels dancing on pins here. Most situations that practitioners face are unique in at least one aspect, and Bob understands the importance of context. You won't find any recipes or overcooked, pre-digested, one-size-fits all advice.

Instead, you will find food for thought.

Eleventh-century philosopher Pierre Abelard taught that, The beginning of wisdom is found in doubting; by doubting we come to the question, and by seeking we may come upon the truth.

Welcome to Bob's essays on software conflict. Here you'll find the seeds of doubt, some underlying questions, and a fellow seeker.

Doubt the dubious promises of new technology. Find the underlying questions that clearly still need asking. Think about what Bob Glass has to say. And don't stop here. Read the sources Bob quotes. Read Fred Brooks and David Parnas. Check out the Pragmatic Programmer books. Read more of Bob's books and articles.

And start asking the right questions.

Andrew Hunt
The Pragmatic Programmers, LLC
www.pragmaticprogrammer.com
October 2005

H umor is an elusive commodity in most technical books. Yet, when it is present, it makes reading about new ideas fun. That's what I like about Bob Glass's writings. He uses sarcasm and wit to communicate his thoughts on controversies that are currently being debated by the leaders of the software engineering community. He is insightful and entertaining when he states his opinions, some of which are quite controversial. He is humorous and humanistic. A great storyteller, he uses revealing anecdotes and parables. Bob Glass is also a teacher who gives us lessons in history, ethics, and philosophy so that he can relate them to his opinions and make his points.

This book is fundamentally about conflict and conflict management. It pits the programmer/software engineer against the manager. It contrasts theory versus practice, discussing stability versus change, talk versus action, and promises versus results. It tries to show us all sides of an argument. It also tries to make us think and reach our own opinions.

The book is also about change and change management. It encourages us to challenge the accepted gospel that change can't happen quickly. It states that there are no panaceas on the horizon in the foreseeable future.

Yet, it asks us to examine why the state of the practice of software engineering has to be so different from the state of the art.

The book's main premise is that conflict is healthy when managed properly because it forces professionals to think through their ideas before they rush to implement them. The basic conflict described is the one that exists between theory and practice. Bob takes the side of the practitioner as he goes on to explain that neither side can make progress without contributions to the other.

As a practitioner myself, I can relate well to Bob's opinions and ampliflying examples. The many battles that I have fought with academics have been in the same arena. The frustrations that Bob expresses are ones that I have felt myself. The arguments that he poses are ones that I have used myself to win battles, but never the war.

The book is controversial because it tries to explode the myths which permeate the literature. Although I agree with Bob on many points, we still have major areas of disagreement when it comes to technology and its transition. I am an evolutionist, while Bob is a revolutionist. I look for incremental progress, while Bob searches for quicker solutions. Yet, that is the purpose of the bookto make people think and help people change.

As much as I like the book, there are some things wrong with it. First, it is too long. Because Bob has so much to say, he often takes too long to get to his main point. Second, the book is too short. Just when you think that Bob will solve your problem, he stops and forces you to think it through yourself.

Needless to say, I recommend that this book be read. Software managers, software engineers, academics, computer scientists, programmers, and technologists could all benefit from its study. Think about what Bob has to say and ponder its meaning. I am sure that you will find that it has value. Don't take things literally as they appear. Bob is the master of disguise as he says things to get your attention and make you think. If you don't agree with him, all the better. At least now you will have an opinion on some of the topics that will shape the field of software engineering as we will know it in the future.

Donald J. Reifer, President
Reifer Consultants, Inc.

C onfict and controversy have been too long avoided in computer science and software engineering. These fields are less than a human generation old, with all the growing pains that accompany youth. Yet in the professional literature we tend to see opinions presented as truth and advocacy presented as fact, with nothing acknowledging the tentative nature of some of these facts and much of this truth. Even noted computer scientist David Parnas has labeled much of our computer science truth folklore, because it has not been experimentally verified.

It isn't that conflict and controversy don't exist in the field. If N computer scientists or software engineers discuss an issue in person, there are often at least N opinions on what is correct or best. (Bill Curtis said it best in his keynote to the 1989 International Conference on Software EngineeringIn a room of 15 designers, if two of them agree that's a majority!)