When All You ve Got Is a Hammer


When All You ve Got Is a Hammer

In the Extremo mind-set, any justification to avoid up-front design is a good one. This fear of up-front design (FUD) is astoundingly similar to the hack-and-whack mind-set . (Is it starting to be clear yet why XP is popular with the hack-andwhack crowd ?)

One of the most popular Extremo justifications for avoiding up-front design is that writing the unit test before writing the code is actually design. In other words, the tests are the design. But, of course, in XP the code is also the design and the tests are also the requirements. So actually everything is code. When all you ve got is a hammer, everything looks like a nail.

As we ve established elsewhere, the Extremos do advocate some up-front design before writing code. The amount varies depending on which Extremo you listen to. Ron Jeffries recommends 10 to 30 minutes at most, after which you should let the code participate in the design session. [4] Martin Fowler, on the other hand, is less extreme ”he suggests a ratio of 20% to 80% (i.e., 20% up-front design followed by 80% refactoring). [5] This is still a lot less than what we feel is a necessary amount of up-front design (for reasons that we go into later in this chapter).

start example

The 20% design/80% refactoring ratio is discussed further in Chapter 12.

end example
 

We don t have anything against writing the unit tests before writing the code, and we don t deny that this forces a certain level of thinking before the code is written, but we beg to disagree that doing this in any way compensates for not designing your software up front. This is because the design issues being dealt with are at entirely different levels of abstraction. What do we mean by this? Unit tests exercise code at a very atomic level of detail. Up-front design, when done correctly, makes sure that larger design issues have been thought through.

Let s explore this thought in a little more detail. If we grossly oversimplify object-oriented design, we can focus on two questions (we were going to say that there are only two important things about software but decided against it):

  • What objects are we going to need?

  • How do we distribute the behavior (i.e., set of software operations) across the objects?

Attempting to answer these questions for an entire system all at once would probably lead to a nasty case of analysis paralysis, so we prefer to ask these questions one scenario (loosely speaking, one user story) at a time. We don t consider this Big Design Up Front; we consider this Enough Design Up Front.

We use sequence diagrams to show the allocation of behavior across objects for a scenario, and we use robustness diagrams (in conjunction with a larger-scope domain model) to give us a first guess at which objects will participate in a scenario. The clean allocation of operations to classes you can achieve on a sequence diagram will eliminate the need for a whole bunch of Constant Refactoring After Programming, because you re going to come a lot closer to getting the design right the first time.

Writing unit tests before coding the methods addresses exactly none of these design issues. A single unit test tends to cover just a small aspect of the design (covering maybe a few methods and one or two classes). Actual up-front design addresses issues on a larger scale: the impact of implementing a given scenario on the overall design.

Extremos tend to want to replace both requirements and designs with code and tests, in somewhat of an interchangeable manner. So in addition to test-first design (or as we prefer to call it, Design After First Testing ) we also see quotes like the three zingers at the start of this chapter.

So, in essence, the Extremo philosophy here is, We have unit tests and refactoring, so up-front requirements elicitation , up-front analysis, and up-front design can be conveniently deemphasized (in certain cases, almost dropped altogether).

Test and Shout

(Sing to the tune of Twist and Shout by The Beatles)

You failed a unit test baby
(Failed the test baby)

But do not shout
(Do not shout)
You failed a unit test baby, now
(Failed the test baby)

So go and rip that code out
(Rip that code out)

You know you code so good
(Code so good)

You know you test so fine
(Test so fine)

I m so glad we re pairing now
(Glad we re pairing)

Instead of doing design
(No design)

Aaaaaaaaaaaaahhhhhhhh

Before you write some code baby
(Write some code baby)

Test and shout
(Test and shout)
Then rewrite it all over
(Rewrite it over)
That s what XP s all about
(What XP s about)

Aaaaaaaaaaaaahhhhhhhh

start sidebar
VoXP
Voice of eXPerience: The Quality Contradiction

by David Van Der Klauw

David provides the following observation on quality in XP (more from him later in this chapter).

XP has a contradiction regarding how it achieves quality. On one hand, it uses exhaustive testing to guarantee quality. XP states that you should write tests first and write the minimum code needed to pass the tests. If all the tests pass, then by definition the product works.

On the other hand, XP claims that programmers must pair in order to write code of appropriate quality.

The obvious question is, if the testing guarantees quality, then why do you need the pairing for quality?

end sidebar
 

[4] Ron Jeffries, Ann Anderson, and Chet Hendrickson, Extreme Programming Installed (New York, NY: Addison-Wesley, 2000), p. 70.

[5] See http://www.artima.com/intv/flexplex.html.




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

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