Who Should Read This Book

A conscious effort has been made to make this book useful to a wide audience that includes professional developers and postsecondary students as well as anyone with an interest in understanding object-oriented thinking. It s assumed that the average reader will have some degree of familiarity with software development, either coursework or experience. It s further assumed that the reader will have been taught or will have experience using the vocabulary, models, and methods prevalent in mainstream software development. This book focuses on presenting objects and XP and not on providing background and details of mainstream development.

The organization of the book, front-loading the philosophical and historical material, might present some problems for the most pragmatically oriented reader, the one looking for technique and heuristics to apply immediately. The introduction attempts to make a case for reading the book in the order presented, but it s OK to skip ahead and come back to the early chapters to understand the ideas behind the technique.

Three caveats help to further define the audience for this book:

• This is not a programming text. Some limited examples of pseudocode (usually having the flavor of Smalltalk, the language most familiar to the author) are presented when they can illuminate a concept or principle of development.

• The book, however, is expressly intended for programmers, especially those using Java and C++. It s hoped that this book will facilitate their work, not by providing tricks and compiler insights but by providing conceptual foundations. Languages such as C++ and Java require significant programmer discipline if they are to be used to create true objects and object applications. That discipline must, in turn , be grounded in the kind of thinking presented in this book.

• Although this book stresses the philosophy and history of objects/ components , the author s overarching goal is assisting people in the development of pragmatic skills.

  Note  

  If this text is used in an academic course ( undergraduate or graduate), roughly 40 percent of the available class time should be devoted to workshop activities. Software development of any kind is learned through experience, but objects, because they are new and different, require even greater amounts of reflection and practice. Another characteristic of an ideal course is interaction and discussion of multiple viewpoints. This book is best used in conjunction with other method books (particularly any of the excellent books on UML or RUP) that present alternative viewpoints and, of course, with at least one of the XP or agile texts , which will add depth to what is presented here.

Portions of the historical and philosophical material in this book will be familiar to those readers with their own extensive personal experience as practitioners. To them, the material might appear to be rehashed old arguments. But most readers will not share either that experience or that awareness, and they need to know, explicitly, how those ideas have shaped the profession as we see it today. I hope that even the most experienced practitioners will see some new insights or have old insights brought to the forefront of their minds when reading this material.

One final note. Readers of this book will tend to be professional software developers or those aspiring to become professionals. Both groups share a character trait ”an eagerness to build, to practice. They are ready to just do it.

To them is directed the final message of this introductory chapter: please be patient.

As a profession, we also tend to be abysmally ignorant of our own history. In the words of the oft quoted, misquoted, and paraphrased philosopher, George Santayana, Those who cannot remember the past are condemned to repeat it. In computing, thanks to Moore s Law, our repetition is disguised a bit by scale ”mainframe mistakes replicated on desktops, then notebooks , then PDAs and phones, and then molecular computers.

As a profession, we tend to ignore the various influences ”such as culture, philosophy, psychology, economics, and sheer chance ”that have shaped the practice of software development.

It is my belief that we cannot improve our intrinsic abilities as object and agile software developers without an examination, however brief, of the historical and philosophical presuppositions behind our profession. We should not, and cannot if we want them to truly understand, bring new members into our profession without providing them with more than tools, methods, and processes that they use by rote.