Object Thinking and Agile Development Practices

The second major objective of this chapter was to provide some initial arguments for the special utility of object thinking to agile developers. To answer this question, let s look at the four XP values and a selection of the 12 XP practices introduced by Kent Beck. ^[10]

Values

We will be successful when we have a style that celebrates a consistent set of values that serve both human and commercial needs: communication, simplicity, feedback, and courage. This statement introduces Kent Beck s discussion of values in eXtreme Programming eXplained and is a suitable introduction for our own examination.

Communication

The communication value has two aspects: advocating greater communication among all team members (developers, users, and managers) and promoting an increase in the quality of communication. Object thinking directly contributes to the latter aspect.

Imagine how much better your communication would be if all team members spoke a common vocabulary and that vocabulary reflected a common understanding of the problem domain and the essence of the problem being addressed by the team. Imagine further that the concepts behind this vocabulary reflected common understanding and did not require the customer side of the team or the developer side of the team to memorize arcane terminology employed by the other side.

Objects and object thinking promise the benefit of a common language. Users, managers, domain experts, and developers will all use the same vocabulary, grounded in a common understanding of that vocabulary, whether they are discussing workflow or programming, requirements (stories) or refactoring. It would be difficult to overstate the importance of a common language, especially in an environment shaped by XP practices, almost all of which require deep levels of communication among all participants in the development activity.

Note  

A domain expert is, by definition, someone with a deep understanding of the problem space and who has an ongoing involvement with that problem space ”a real live customer, in other words. A software professional who has merely developed systems for that kind of problem area before is not a domain expert. This is one reason why XP demands an on-site customer.

Simplicity

Every aspect of object thinking shares a common goal with this XP value, which equates to finding the simplest thing that could possibly work. Some examples:

• Object identification and responsibility assignment are based on the structure of the problem domain rather than on the structure of some potential computer program “based problem solution. However complex or complicated the natural world appears, human beings do very well in coping with that world. This suggests that a kind of natural simplicity is implicit in that world and is waiting to be discovered and employed. ^[11]

• Object thinking will lead to the smallest number of distinct things (represented as classes) possible ”a kind of numerical simplicity.

• Objects designed and constructed following the application of object thinking will do the least amount of work possible and do it in the most direct and simplest way possible.

• Focusing on coordination of autonomous objects instead of the control and management of unruly modules and passive data structures will also contribute to simplicity.

Feedback

Object thinking s contribution regarding feedback is somewhat indirect. Object thinking evolved, in part, from the rapid prototyping school of software development and shares the values of immediate feedback that arose there. Object tools, such as the Smalltalk programming language, were optimized to provide immediate feedback to developers. Both the use of an interpreted language and the provision of multiwindowed development environments with browsers and workspaces are manifestations of this desire for rapid feedback. Consider the importance of the kind of immediate feedback described by Michael Hiltzik when talking about Apple s famous visit to Xerox PARC:

Given this rare psychic encouragement, the Learning Research Group warmed to their subject. They even indulged in some of their favorite legerdemain. At one point Jobs, watching some text scroll up the screen line by line in its normal fashion, remarked, It would be nice if it moved smoothly, pixel by pixel, like paper.

With Ingalls at the keyboard, that was like asking a New Orleans jazz band to play Limehouse Blues. He clicked the mouse on a window displaying several lines of Smalltalk code, made a minor edit, and returned to the text. Presto! The scrolling was now continuous.

The Apple engineer s eyes bulged in astonishment .

Courage

Object thinking embodies precisely the kind of courage advocated by Kent Beck:

Every once in a while someone on the team will have a crazy idea that just might slash the complexity of the whole system. If they have courage, they ll try it out. It will work (sometimes).

Object thinking is a crazy idea capable of increasing simplicity in software design ”crazy in the sense that it does not conform to traditional thinking about software development, crazy in the sense that it revolts against the computer thinking employed by most software developers, and crazy in many of the same ways that XP is crazy. It takes courage to take a stand in opposition to conventional wisdom as to how software should be developed. It takes courage to suggest that formal practices, scientific practices, and engineering practices are not necessarily the best way to develop software and that we might learn something from philosophy, anthropology, and art.

Courage is not just crazy ideas and the ability to take advantage of them. Courage is the ability to confront and overcome fear:

• Fear that changes will break your software. Properly constructed objects, enforced encapsulation, and diligent refactoring based on solid object thinking reduce the risks associated with change to a negligible level.

• Fear of mistakes. Mistakes are simply one iteration in the learning cycle. Object thinking is grounded in the idea that exploration and experimentation are intrinsically valuable and that learning what doesn t work is just as important as learning what does work. There are no mistakes: every result tells you something of value about what you are trying to accomplish.

• Fear that change will be costly. Change is costly only if the effects of a small incremental change in one part of a system are propagated throughout the system and somehow precipitate widespread failures in other parts of the system. Objects and object thinking assure that change is a local, not a systemic, phenomenon .

Selected Practices

Although it would be possible to link object thinking with all of the practices advocated by XP, a few merit explicit mention.

Metaphor

Metaphor is one of the most important but least understood practices of XP. Some ^[12] would claim that all thinking is metaphor-based. Kent Beck spent his OOPSLA 2002 keynote talking about the importance of metaphor. Object thinking introduces a very different set of metaphors to use in talking and thinking about software development. Object thinking metaphors are compatible with XP and are an important complement to XP metaphoric thinking. The common language provided by objects and object thinking provides a system of metaphors: every story, every test, every code module employs labels and terms that metaphorically connect things in the domain with their simulated coded counterparts.

Simple Design

Object thinking leads to simple design (usually the simplest design possible); the least number of classes necessary; the fewest number of methods per class possible; the simplest coding of methods ; the avoidance of control, centralization, and management classes; and simple scripts to simulate simple stories.

Refactoring

Refactoring is a way for lazy objects to give all the hard work to other objects. Of course, when refactored and distributed to the proper objects, the work turns out not to be hard at all. Whenever a task looks too hard for a good object to perform by itself, it looks for others to share in the workload. Successive passing of hard work to others results in no object doing anything really difficult ”and usually in a collective solution that is intrinsically simpler than would have been possible if the work had remained where originally assigned.

For example, suppose an airplane object has a responsibility to report its location. This is a hard task because the location is constantly changing; a location is a composite structure (latitude, longitude, altitude, direction, speed, and vector); the values of each part of that structure come from a different source; and someone has to remember who asked for the location and make sure it gets back to them in a timely fashion. If the task is broken up so that

• The airplane actually returns a location object to whoever asked for it after appending its ID to the location so that there is no confusion about who is where. (We cannot assume that our airplane is the only one reporting its location at any one time.)

• An instrument cluster keeps track of the instruments that must be asked for their current values and knows how to ask each one in turn for its value (a collection iterating across its contents).

• An instrument merely reports its current value.

• A location object collects and returns a set of label:value pairs (altitude:15,000 ft.).

None of the objects do anything particularly difficult, and yet collectively they solve a complicated problem that would be very hard for any one of them to accomplish individually.

On-Site Customer

The value of the on-site customer increases when she can fully participate in the development work by virtue of the common vocabulary described earlier in the Communication section. Object thinking not only creates a common vocabulary but also allows the on-site customer to actually make design suggestions and validate emerging designs as powerful representations of business context and goals because the behavior of objects is simple, transparent, and as familiar to the user as it is to the developer.

Coding Standards

Let me quote Kent Beck again: Programmers write all code in accordance with rules emphasizing communication through the code. Object thinking promotes this kind of coding. In fact, much of what will be presented on coding later in this book is strongly influenced by Beck s Best Smalltalk Practice Patterns (Prentice Hall PTR, 1996), a style book for good coding. The coding metrics noted earlier ”lines of code per method and number of methods requiring inline comments ”are consistent with this XP practice.

As in the rest of this introductory chapter, I m making assertions and claims about object thinking ”here specifically about object thinking s compatibility with XP ”that will be proved (or not) in the chapters that follow.

^[10] Beck, Kent. eXtreme Programming eXplained: Embrace Change . New York: Addison-Wesley. 2000. ISBN 201-61641-6.

^[11] Christopher Alexander s current works on the nature of order ( http://www.patternlanguage.com ) are a quest to find this natural ”but exceedingly powerful ”simplicity.

^[12] George Lakoff, for one. His work on cognition represents a fairly dramatic shift in this area of study, and his findings are very important for software developers.