Chapter 13: Embracing Change (Embrace People, Manage Change)


Overview

Changes

(With apologies to David Bowie)

I still don t know what I d need design for
And my code was running wild
A million dead-end arraylists
Every time I thought I d got it made
It seemed the code smell was not so sweet
So I turned my pair to face me
But I ve never caught a whiff
Of how the others must smell the
Smalltalk I m much too fast to unit test

Ch-ch-ch-ch-changes
(Tryin to embrace change)
Ch-ch-changes
Don t want no specifications, man
Ch-ch-ch-ch-changes
(Tryin to embrace change)
Ch-ch-changes
Just gonna have to toss that code and start again
Got no deadlines
So I can waste time

I watch the iterations change their size
But never leave the stream
Of those acceptance tests and
So the code floats past my eyes
But still the days all seem the same
And this snack food that we munch on
As we try to embrace change
And receive congratulations
On the marvelous agility we re going through

Ch-ch-ch-ch-changes
(Tryin to embrace change)
Ch-ch-changes
Don t tell them to pair up and where to sit
Ch-ch-ch-ch-changes
(Tryin to embrace change)
Ch-ch-changes
The planning game
You ve left us up to our necks in it
Got no deadlines
So I can waste time

Strange code smells, fascinating me
Changes are shaking the code I m going through

Ch-ch-ch-ch-changes
(Tryin to embrace change)

Ch-ch-changes
Oh, look out you junior coders
Ch-ch-ch-ch-changes
(Tryin to embrace change)
Ch-ch-changes
You just need to get a little bolder
Got no deadlines
So I can waste time
We do XP
So we can waste time

GROUCHO  

Requirements creep is perfectly reasonable and rational, even valuable . [1]
”Kent Beck/Martin Fowler

GROUCHO  

A project *without* rapidly changing requirements is a project that nobody cares about and nobody really wants. [2]
”Robert C. Martin

GROUCHO  

Please tell me a story where the moral is, ˜And that s why I am ever so happy that I tracked requirements changes . [3]
”Ron Jeffries

The primary message in XP is to embrace change. It s the maxim that appears on the front cover of the first XP book, Extreme Programming Explained . Despite occasional protestations to the contrary, the Extremos encourage us to embrace change and to follow a software process that makes changes to requirements almost a certainty .

In this chapter we examine this aspect of XP.

start sidebar
Constantly Fighting Emergent Entropy

The more code that has been written, the more difficult, time-consuming , and error-prone any change is likely to be. XP attempts to reduce this problem with constant refactoring, pair programming, unit tests, and so on, but as we will soon see (and as we will also see in the case study in the next chapter), emergent entropy (in which the code breaks down over time) is a likely outcome of the emergent design approach. So, as the codebase becomes more complex, the cost of making a change to the code increases .

end sidebar
 

[1] Kent Beck and Martin Fowler, Planning Extreme Programming (New York, NY: Addison-Wesley, 2000), p. 71.

[2] Robert C. Martin posting to the newsgroup comp.software.extreme-programming, subject: Why eXtreme Prejudice against XP? August 8, 2001.

[3] Ron Jeffries posting to the C2 Wiki page Requirements Tracking, http://c2.com/cgi/wiki?RequirementsTracking.




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