The Perpetual Coding Machine (Embracing Change)


The Perpetual Coding Machine (Embracing Change)

GROUCHO  

Even though you don t really have to release for six months or a year, releasing every couple of months can really pay off. You don t want to pass up the chance to learn what users really want. You don t want to pass up the increasing confidence that will come from showing people that you have done something useful. And you don t want to pass up the sheer thrill of releasing useful software into the universe. [11]

Um, riiiiight.

In a project that is releasing early and often to end users, there is an increased risk that the software will never be done. This is because each iteration from the first release onward involves maintaining legacy code (which must in turn be changed because the users aren t happy with the first few versions). The Extremos viewpoint, not surprisingly given their case history, is that a project that continually undergoes revisions until it is finally cancelled is a sign of success.

Ron Jeffries sheer thrill of releasing useful software into the universe is tempered by the fact that the user is likely to want the software changed. Our own sheer thrill comes from delivering a piece of software to the user s satisfaction and from knowing that it s completed ”that it s time to move on and deliver something else. This is the satisfaction of getting the job finished.

Why do XP projects risk going round and round, covering the same old ground? The evidence suggests that this is what happened on C3 (as we explored in Chapter 2). The problem that XP suffers from is that it spins at two levels: at the requirements (user story) level and at the design level.

Spinning a Story

GROUCHO  

Requirements creep is perfectly reasonable and rational, even valuable . The requirements can creep wherever they like as long as we know where they are going and the customer is informed of the consequences. Indeed, we encourage the requirements to crawl around and find whatever it is the customer needs. [12]

Surely (we would suggest), the requirements spin because not nearly enough effort is put into getting them right in the first place. Apart from the initial brief exploration phase, very little time is spent helping the customer understand what it is she is really asking for. [13] Instead, the XP mechanism to achieve this understanding is to release the project early and get user feedback on a working system. [14] The requirements for subsequent iterations may then change (or new requirements discovered ) based on this feedback.

This sounds okay, except that in order to make this really work, XPers must accept scope creep as a natural part of the project. To an extent, scope creep is a natural part of any project, but XPers go several steps further and embrace scope creep as a good thing: a way to extract the body of correct requirements from the customer. We feel that these requirements should be identified much earlier.

Does Agile Mean Fast?

XPers see scope creep as being an important part of software agility. [15] The ability to accept new requirements late in a project is what makes a project agile. However, this isn t the same as following a process that causes requirements to be discovered late in a project (and embraces the cause with courage ).

Instead, why not follow a process that accepts scope creep as an occasionally-necessary evil and makes it possible to add requirements late in the project, but that doesn t go out of its way to make scope creep more likely?

A large part of XP is about planning and making estimates gradually more accurate by tracking the velocity of each iteration. However, XP s wholesale acceptance of scope creep kind of throws a wrench in the works and (for the reasons we ve described) makes it more likely that requirements will lurk undiscovered until late in the project.

Spinning the Design

The design also gets spun perpetually because in XP coding is never finished. A task might be signed off and pass all its unit tests, and the overall story (or stories) to which the task contributes might pass all its acceptance tests, but the lid is never quite fully closed on the code. A different pair of programmers working on a different task might find that their task needs the finished code to be changed, or they might simply decide that the design could be refactored, without any particular goal in mind except to make the code cleaner.

start example

We discuss the problem of Constant Refactoring After Programming in Chapter 9 and emergent design in Chapter 12.

end example
 

This makes planning difficult. The team might eventually reach a constant velocity by factoring in the refactoring process [16] (seeing it as a constant, concurrent process that persists throughout the project), but the velocity is likely to be much slower than if the team had spent time getting the design right up front (as we discuss in Chapter 12).

The Extremos see the concept of getting the design right up front as something that just isn t realistic ”something that would be great if this were a perfect world but really just can t be done reliably. We ve spent a lot of time in this book trying to convince you otherwise : that it is possible to get a design right prior to coding; that this can be done predictably, by following specific methods (a logical process); and that doing this minimizes the amount of postcode refactoring needed. [17]

start sidebar
Constant Refactoring Not Realistic in Small Companies

One of our Voice of eXPerience interviewees, Robin Sharp, suggested that XP might be better suited to large companies in which entire projects can hide behind department budgets and be left to linger for years at a time, blithely dismissing the notion of doneness. In small companies (e.g., tech start-ups) where resources are tight (and probably paid for by venture capitalists), every piece of work needs to be budgeted for and fully justified.

In the latter case (as happened on the XP project Robin was involved in), the managers would be very happy to embrace the no up-front design and no detailed up-front requirements capture aspects of Extremo culture, but they would not be so keen on the refactoring code that we thought was already finished aspect.

Of course, this problem is not insurmountable. A lot depends on the mentality of the managers and on the extent to which they micromanage the programmers lives. However, XP s emergent design approach does not fit comfortably with small company management dynamics.

end sidebar
 
start sidebar
VoXP
Voice of eXPerience: The Simplest Build System

by David Van Der Klauw

Our build system had evolved over the years from BAT files to VBScript. Although it had become a bit complicated, it did have concise logging, checked for most errors, and immediately stopped and reported errors.

When XP was introduced, a new team needed a cut-down integration build. I suggested basing it on my build system but simplifying certain sections. This would have taken maybe 2 days of work.

The team members rejected this idea because my build system was too complicated and, in XP fashion, they were determined to do the simplest thing that could possibly work ”BAT files, they thought.

Their BAT file build was simple, sure enough: no error checking, no logging, and pages and pages of useless output with a critical error buried in the middle. It was impossible to debug and never worked properly.

Various pairs spent 8 weeks on this abomination, adding more and more BAT files, more and more layers of simplest possible solutions, before it was finally scrapped.

end sidebar
 
start sidebar
Pair-Watching the Progress Bar

To maintain all development PCs at the same state, our team would create an image of a PC and load it onto a clean PC. Before XP, Nandor did a good job of all the imaging for the team.

Under XP, it was decided that everyone had to do imaging and it had to be done in pairs. Under XP, the team had only one PC per pair, so during the lengthy imaging process, there was nothing else to do, and you had two people sitting there watching a progress bar move for half an hour .

Every half hour the coach insisted that a new member swap in to the pair. So the new member could watch the progress bar move from, say, 30% to 70% in that half hour.

Anyway, some weeks after this nonsense had occurred, it became necessary to update the image. I asked the team, Who can tell me how to do the imaging?

It turned out that no one could. Each person had been swapped around so much that no one had seen the whole process, nor understood it, nor remembered it. I had to go outside the team to find the expertise. Fortunately, Nandor was still with the company at this stage.

end sidebar
 

Project s Not Going Too Far

(Sing to the tune of Back in the USSR by The Beatles)

Overtime is evil when you do XP
Gotta leave at five PM each night
Schedule s not our problem because change is free
Man, Kent really got it right

Project s not goin too far
Find out how lucky you are, boy
Cause your project s not goin too far

This code has been refactored by a chimpanzee
Maybe it needs a rewrite
What that ape was thinkin about I just can t see
Maybe he s just not too bright

Project s not goin too far
I dunno how lucky you are, boy
Cause your project s not goin too far

We put code in and we rip it out
We leave a mess behind
Refactoring s what it s all about
Ain t no time for design-nine-nine-nine-nine-nine-nine-nine-nine

Going round in circles each and every day
Is not a cause for alarm
When we throw the stack of index cards away
We re not doing any harm

Project s not goin too far
I dunno how lucky you are, boy
Cause your project s not goin too far

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

[12] Kent Beck and Martin Fowler, Planning Extreme Programming , op. cit., p. 71.

[13] The customer also spends a lot of time writing tests, which in XP is considered to be discovering and writing requirements. More about that in Chapter 10.

[14] It was suggested to us that acceptance tests are also a mechanism for this purpose. However, acceptance tests aren t a mechanism for understanding the requirements; they re a mechanism for verifying that the requirements have been implemented by the programmers.

[15] Note that many people might associate the word agile with the words quick or fast. But the meaning is considerably different. Organizing your software process to embrace changing requirements means it takes a long time to get done!

[16] Factoring in refactoring? Isn t it refactoring in factoring? This reminds us of Groucho Marx in Horsefeathers : Anything further, father? That can t be right. Isn t it anything farther further?

[17] Doug has actually gone to the trouble of writing two books that explain how to do this reliably. This topic is beyond the scope of this book, though.




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