Thinking Is Key


There was a time when software development was considered an art. Art implies individual talent based on innate skills: Artists are born, not made. As computers became increasingly prevalent and essential to modern industrial life, the dependence on artists to create the software that made them useful was deemed undesirable. Some were even offended that a computer ”the embodiment of rationality, mathematics, and hard science ”could be corrupted by mere art. Increasing demand for programming and development services suggested that the pool of true artists was too small; some other way would have to be found to create the mass of individuals needed to fill all the jobs available.

In the early sixties, a movement to eliminate art from development came to dominate the way we thought about the manufacture (the terms educate and train were used, but only as euphemisms for manufacture ) of software developers. Tools would automate most of the development tasks , defined method would replace idiosyncratic problem solving, and documented process would allow every step to be monitored , measured, and controlled. Even the most mediocre human raw material could generate superior results if all the tools, methods , and processes were deployed properly.

The preface to this book begins with quotes from Robert L. Glass that suggest that the attempt to eliminate humans ”or at least humanity ”from software development failed. Humans and human abilities are still the key to software development success. This, in turn , suggests that we need to reconsider how we go about enhancing human abilities instead of attempting to replace them with machine capabilities.

One small step in this effort is to reconsider the artists are born, not made dictum. Thousands of art schools ( ranging from small commercial academies to graduate academic programs) claim to make artists. While it may be true that no school creates artists on the order of Michelangelo or Georgia O Keefe quality, they do enhance the innate talents of individuals and make them the best artist they can be. The education of artists is not focused on technique, process, or tools. The majority of an art education combines ideas, history, appreciation , experience, and constructive criticism.

An artist who is aware of the philosophy and history behind the practice, an artist who is attuned to the community in which art is created and appreciated, an artist who is capable of deep communication, is a better artist.

This book believes the same thing to be true of software developers ”software artists, software professionals. Mastery comes first from a thorough understanding of ideas. Understanding of ideas requires an understanding of context, including historical context. Mastery is shared ”it is a property less of the individual than of the group ”and is shared by those participating in a common culture.

Software Development Is a Cultural Activity

To succeed, a software developer must be able to comprehend enterprise domains and perceived problems within those domains, conceptualize alternative configurations of artifacts and processes, and articulate ideas in a number of languages ”at a minimum, a natural language, a modeling language, and a programming language. Because all of these activities involve thinking, improving a developer s cognitive abilities will result in improvement in the software he or she produces. This would seem obvious, but little has been done in the world of computing and software development to directly address this issue. Instead, the majority of software improvement efforts have focused on languages, tools, methods, and processes rather than on how to think about software.

In fact, efforts to reform software development by introducing a new way of thinking about software or about development are usually met with significant resistance. More often than not, new ways of thinking are dismissed out of hand or are co- opted and corrupted until they are acceptable to mainstream developers. At that point, they are but pale imitations of the original ideas.

An observer of these conflicts over the past 50 years cannot help but be struck by the similarity between the language wars, formalism wars, and method wars occurring within the software development community and ethnic and religious conflicts in the world at large. In fact, our conflicts over how to think about software development reflect real, but usually tacit, cultural differences ”the most obvious example being tacit assumptions about the value of rationalism.

We live in a culture in which the value of, and the esteem given to, science and rationality are so deeply embedded that we seldom consciously consider why we have this pervasive bias. We do not question how and why this bias became entangled in other aspects of our culture ”gender, for example, where a traditional association of rationality with the male gender and irrationality with the female was used as a justification for perpetuating unequal treatment based on gender. This same bias in favor of rationality is reflected in debates over method ”the implicit assumption is that a method is weak unless built on a formal (rational, logical, mathematical) foundation. And it shows up in debates about programming languages, which not only must be formal but must resolve every hint of potential ambiguity, even to the point of adding features capable of resolving conflicts that are unlikely to be encountered by any programmer anytime in the next thousand years.

Note  

I ll say much more about cultural, and usually tacit, assumptions in the next two chapters.

Five significant software development innovations and trends have gained prominence in the past 50 years: datacentrism, software engineering, object orientation, patterns, and extreme programming. (Although computer-aided software engineering [CASE], total quality management [TQM], and capability maturity model [CMM] have been prominent innovations in software development, they were not, and are not, primarily new ideas about how to think about software.) Datacentrism ”that is, focusing on data entities, relations, and databases instead of algorithms, flow charts , and data-flow diagrams ”has been the most successful of the five thinking innovations, although most developers still think procedurally when writing code. Both software engineering and object orientation have achieved a strange status ”everyone claims to be doing them without really doing so. The patterns movement exists mainly as a buzzword , and the jury is still out on extreme programming.

Antipathy toward new ideas, especially ideas that represent radical challenges to the perceived wisdom of formal methods and formal processes, contributes to the demise of radical new ideas. But so too does the failure to articulate radical ideas as ideas . Too often, proponents present their ideas in a guise supposedly more acceptable or easier to communicate ”for example, objects in terms of a programming language (Smalltalk) or interface design as a set of standards, or extreme programming in terms of being a method. This kind of presentation almost always weakens the force of the new idea, making it even more difficult to overcome opposition and avoid co-option and dilution.

Extreme programming ”and to a great extent all of the agile methods ”represents a new and creative idea about software development (that is, an idea based on old and proven practices, reformulated, and taken far more seriously). The essence of this new idea might be distilled to a single sentence : Software development is a social activity. Of course, it will take an entire series of books to explicate this simple idea and all of its implications. But the ultimate success of XP is dependent on people understanding and accepting the idea , and the body of thought presupposed by and supporting that idea, rather than on simply adopting the twelve practices.

start sidebar
Behind the Quotes ”Ward Cunningham and Kent Beck

Ward Cunningham is an almost mythical figure in the world of objects and extreme programming. Excepting a few papers, usually coauthored by Kent Beck, he has published little. His influence, however, has been monumental. He is considered to be the inspiration for most of the extreme programming practices, is a legendary coder and designer, and is a great mentor. Mathematicians use an Erdos Number as an indicator of their association with Paul Erdos, one of the most prolific and brilliant mathematicians of the past century. Erdos himself had the number 0, those who coauthored a paper with him had the number 1, coauthoring with a coauthor yielded 2, and so on. Extreme programmers are given a Ward Number based on pair programming with him (1), pair programming with someone who paired with him (2), and so forth.

Kent Beck is to Cunningham as Plato was to Socrates ”the extender of ideas, contributor in his own right, and, in an interesting parallel, the one who published. The preeminent figure in the world of extreme programming today, Beck was equally active in object programming. Although he did not publish a book on behavioral object modeling, he did publish works on programming style and idiom (for Smalltalk).

Kent Beck and Ward Cunningham were a team when objects first became a hot technology, collaborating both as developers and as creative thinkers about object technology. Both will become quite familiar to the reader, as their ideas are central to many of the themes in this book.

end sidebar
 

Implicit in the idea of XP are other supporting ideas. Notable among these is the idea of objects . This is not surprising given that XP gurus Ward Cunningham and Kent Beck played a central role in the object revolution. They are the inventors of the CRC (Class-Responsibility-Collaborator) card approach to object analysis. The kind of object thinking introduced by Cunningham and Beck was, and is, far more consistent with the original object idea than any of the other popular approaches. The majority of developers claiming to be following object-oriented principles use the approach popularized by Rational Software under the umbrella of UML with nuances introduced by the Java programming language. Although Grady Booch, one of the principal contributors to UML thinking, clearly understood and advocated the object idea in his early work, little of that understanding was codified into UML.

start sidebar
The CRC Card Approach

The project that brought object programming into the mainstream was the development of Smalltalk at Xerox PARC in the 1970s. The first ideas about discovery and specification of objects arose in that context ”Object Behavior Analysis (OBA) was the method developed by Adele Goldberg and Ken Rubin. This method was never published ”except for one brief paper ”but despite the flaw of overzealous formalism, it created part of the foundation for behavioral object thinking.

Ward Cunningham developed the foundation for what was to become a simple and powerful mechanism for capturing and understanding object behavior ”a simple 3 — 5 index card. The index card provided a means for exploring and documenting a development team s understanding of objects. The format of the card was simple: a class name appeared at the upper left corner, and two column headers, Responsibility and Collaborator, appeared on the next line of the card. Class, Responsibility, Collaborator (CRC) headings yielded the popular name for the cards and the approach to analysis and design based on those cards.

Figure 1-5 shows part of a completed CRC card for an airplane object.

click to expand
Figure 1-5: A partial completed CRC card for an airplane.

Chapter 6, Method, Process, and Models, will introduce more detail about CRC cards and how they became the foundation for the Object Cube at the center of applied object thinking and modeling introduced in this book.

end sidebar
 

Object thinking is central to extreme thinking. This is true even though there is little explicit mention of objects in the XP books. Object thinking is so basic to XP that it is simply assumed. As with cultural practices, it seldom occurs to members of a given culture that there is any need to explicitly talk about those practices ”you simply do them the way everyone does. Many of the XP values and practices ”for example, simplicity, stories, and refactoring ”are dependent in important ways on object thinking.

XP values and practices aren t based on just any flavor of object thinking. Object thinking in XP is based on the behavior-centric ideas about objects exemplified in the CRC card approach. This approach to object thinking was always a minority view and almost disappeared as UML attained dominance and C++ challenged Smalltalk. (Visual Basic and Java superseded C++ in popularity and offered an improvement for object thinking, but still not an optimal environment.) Minority status was almost assured because of the close association of the Smalltalk programming language with behavioralism, an informal, human-centric method in a culture dominated by a bias in favor of formalism and engineering.

Oft-cited reasons for the demise of Smalltalk and the behavioral ideas behind informal methods (such as CRC cards) include performance issues, scaling issues, and hyperbolic promises by expensive consulting companies leading to dramatic failures. These reasons appear to be little more than rationalizations since every innovation in software has been subject to the same criticisms. If an innovation can claim a formal foundation (relational databases), it s given time to overcome its limitations (or those limitations are ignored, and the innovation is used in spite of them).

Note  

The same forces that are bringing XP to the forefront of software development have generated a resurgent interest in the behavioral approach to object thinking. In addition to this work, Rebecca Wirfs-Brock and Alan McKean have published Object Design (Addison-Wesley, 2003), and Richard Pawson and Robert Mathews have published Naked Objects (John Wiley & Sons, 2002), both of which strongly advocate and update behavior-based object thinking.

The purpose of this book is to help you become a better software developer and a better agile developer by improving the way you think. Thought, however, is not simply a matter of rote memorization and repetition of a few facts; it requires an understanding of ideas, of metaphors, and of history, topics that many readers will find unusual in a computer book. Changing your mind requires that you change your worldview , your culture, to include not only new ideas but new values and new perspectives. This, in turn, requires a temporary suspension of your current mindset. You must be prepared to take objects and object thinking seriously. An important aspect of taking the object idea seriously is a willingness to change your mind, to give up (at least temporarily) old and sometimes cherished ideas that are in conflict with new ones. Many of the original proponents of object ideas overdramatized the need for a mental change. ( Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy. ) Predictably, this alienated potential converts to the new ideas more often than it convinced them. I ll try to avoid this error in this book, while at the same time emphasizing those occasions when you really must think differently in order to think in an object-oriented fashion.

Of course, the object idea is not a single idea. It s a complex of interrelated ideas that provide a kind of philosophy or, perhaps more accurately, a mental perspective. This perspective shapes the software developer s thoughts constantly and pervasively whenever a decision needs to be made, a problem needs evaluation, or a design requires formulation. It matters little whether the actual development act involves coding, testing, analysis, or design ”the object perspective influences that mental activity.

Object thinking will be most effective only after the developer internalizes the object perspective. The same thing can be said about extreme programming. In both cases, the novice is confronted with an array of terms, of practices, of examples that constitute a gate (to use Christopher Alexander s and many a Zen mystic s terminology) that must be passed through to attain full mastery. As I introduce vocabulary, models, and examples, remember that these are but expressions of the idea (the gate), not the idea itself.

My excursion into history and philosophy in this book is intended to expose the cultural foundations of our thinking about software development. It will accomplish, hopefully, two things: expose the origins of divergent schools of thought (XP and objects on one side; traditionalist computer scientists and software engineers on the other) and provide the cultural context necessary to fully assimilate the material in later chapters.




Microsoft Object Thinking
Object Thinking (DV-Microsoft Professional)
ISBN: 0735619654
EAN: 2147483647
Year: 2004
Pages: 88
Authors: David West

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net