code? What should we do?
This revolution came at an opportune time. During the middle to late 1990s, Object Mentor was
helping quite a few companies with OO design and project management issues. We were helping
companies get their projects done. As part of that help, we instilled into the teams our own attitudes
and practices. Unfortunately, these attitudes and practices were not written down. Rather, they were
an oral tradition that was passed from us to our customers.
By 1998, I realized that we needed to write down our process and practices so that we could better
articulate them to our customers. So I wrote many articles about process in the C++ Report.
[1]
These articles missed the mark. They were informative and in some cases entertaining, but instead of
codifying the practices and attitudes that we used in our projects, they were an unwitting
compromise to values that had been imposed on me for decades. It took Kent Beck to show me that.
[1]
These articles are available in the publications section of www.objectmentor.com. There are four articles. The first three are
entitled "Iterative and Incremental Development" (I, II, III). The last is entitled "C.O.D.E Culled Object Development process."
The Beck connection
In late 1998, at the same time I was fretting over codifying the Object Mentor process, I ran into
Kent's work on Extreme Programming (XP). The work was scattered through Ward Cunningham's
wiki
[2]
and was mixed with the writings of many others. Still, with some work and diligence, I was
able to get the gist of what Kent was talking about. I was intrigued but skeptical. Some of the things
that XP talked about were exactly on target for my concept of a development process. Other things,
however, such as the lack of an articulated design step, left me puzzled.
[2]
The website http://c2.com/cgi/wiki. contains a vast number of articles on an immense variety of subjects. Its authors number in
the hundreds or thousands. It has been said that only Ward Cunningham could instigate a social revolution using only a few lines
of Perl.
Kent and I could not have come from more disparate software circumstances. He was a recognized
Smalltalk consultant, and I was a recognized C++ consultant. Those two worlds found it difficult to
communicate with each other. There was an almost Kuhnian
[3]
paradigm gulf between them.
[3]
Any credible intellectual work written between 1995 and 2001 must use the term Kuhnian. It refers to the book The Structure of
Scientific Revolutions, by Thomas S. Kuhn, University of Chicago Press, 1962.
Under other circumstances, I would never have asked Kent to write an article for the C++ Report.
But the congruence of our thinking about process was able to breech the language gulf. In February
1999, I met Kent in Munich at the OOP conference. He was giving a talk on XP in the room across
from where I was giving a talk on principles of OOD. Being unable to hear that talk, I sought Kent out
at lunch. We talked about XP, and I asked him to write an article for the C++ Report. It was a great
article about an incident in which Kent and a coworker had been able to make a sweeping design
change in a live system in a matter of an hour or so.
Over the next several months, I went through the slow process of sorting out my own fears about
XP. My greatest fear was in adopting a process in which there is no explicit upfront design step. I
found myself balking at that. Didn't I have an obligation to my clients, and to the industry as a whole,
to teach them that design is important enough to spend time on?
Eventually, I realized that I did not really practice such a step myself. Even in all the article and
books I had written about design, Booch diagrams, and UML diagrams, I had always used code as a