XP Design Mantra: YAGNI


YAGNI

(Sing to the tune of Let It Be by The Beatles)

If you think of building architecture
But you re feeling lazy
You can just skip it
YAGNI

If you think you might need infrastructure
You don t have to worry
Go ahead and skip it
YAGNI

YAGNI
YAGNI
YAGNI
YAGNI

Don t worry bout tomorrow
YAGNI
You aren t gonna need it
YAGNI

XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used anyway. [4]
”Kent Beck

The XP mantra you aren t gonna need it (YAGNI) is about not adding a feature until the iteration it is needed. YAGNI also sums up the XP practice of emergent design. It is in some ways the antithesis of up-front design: not thinking ahead versus thinking ahead (see Figure 12-1). YAGNI represents a myopic approach to software development.

click to expand
Figure 12-1. Never add functionality early

YAGNI is really a product of the parallel Extremo culture (even though it also crops up here and there in the XP books). As such, it gives a stronger, almost militant message than new XP ”YAGNI is a product of the Old Testament, the angry years , when XP was new and a vengeful, no- nonsense god was needed to communicate a clear and unambiguous message to the unwashed. Anyway, where was I?

start example

We discuss YAGNI in the context of Extremo culture in Chapter 4.

end example
 

As the previous quote from Kent Beck suggests, XP is making a bet. We would say, better still, don t bet! If you have planned, architected, and designed properly, you re much less likely to have to throw away any work.

In fact, Beck s quote plays down the amount of rewriting that typically takes place in an XP project. To justify this approach, Beck (in Extreme Programming Explained ) uses the example of a general-purpose dialog for displaying text. He explains that a programmer needed to display a message dialog but decided to make the dialog multipurpose in case anyone else would like to use it. Two days were then spent writing the smart dialog, after which the requirements had changed and it wasn t needed anyway.

This is a fine example, and of course it would have been much better to simply-write a single dialog to display that one message (probably one line of code). Nobody else had asked for a multipurpose dialog, after all. This example is used as the basis for Beck s simplicity value (i.e., code only the features that you need).

Of course, you don t need to be doing XP to do that. The main difference is that without XP, you would have a documented design produced up front; hence, you would know simply by checking the design whether anyone else was going to need the same dialog. It s then possible to make a pretty intelligent decision about whether the time spent coding a smart dialog is justified. With XP, you just can t do that because tomorrow s design document doesn t exist yet. You re still coding it.

start sidebar
Top 10 Emergent Architectures We Hope We Never See

10. Payroll

9. PC operating system

8. Telephone switch

7. Electronic funds transfer

6. LASIK beam control software

5. Autopilot

4. NORAD early warning system

3. Space station environmental control

2. Missile guidance

1. Air traffic control

end sidebar
 

[4] Kent Beck, Extreme Programming Explained: Embrace Change (New York, NY: Addison-Wesley, 2000), p. 31.




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