Circle of Life or Circle of Snakes?


Circle of Life or Circle of Snakes ?

The tightly meshed nature of XP s practices and activities makes them like a ring of poisonous snakes, daisy-chained together. All it takes is for one of the snakes to wriggle loose, and you ve got a very angry , poisonous serpent heading your way. What happens next depends on the snake and to an extent on how good you are at damage control.

To quote Kent Beck again:

Each of the practices still has the same weaknesses as before, but what if those weaknesses were now made up for by the strengths of other practices? We might be able to get away with doing things simply. [7]

The latter sentiment is admirable, although it could be argued that software development done properly is simple enough already. However, the real problem behind this approach is that XP becomes a high-risk proposition. What happens if an XP team makes even am in or digression from the sacred practices? Well, you re probably in trouble, because each practice only works when supported by some other practice; in effect, the XP practices are like a house of cards or a ring of snakes.

Each snake, or XP rule, can be made safe only by daisy-chaining it to the next snake, and so on:

SOLUTION  

No detailed written requirements means the project leaps underway without any formalized requirements (just some user stories handwritten on small cards) and without a particularly solid idea of where it s going to end up. This is a likely scenario because XP is aimed at risky projects with dynamic requirements [8 ] (for instance, converting legacy payroll systems to be Y2K compliant). Due to XP s promises, such a project will likely go ahead, whereas in reality land, the brakes should be slammed on and the project examined to find out how its risks can be reduced before any real expense is committed. Nevertheless, vague and sporadic (sorry, dynamic ) requirements [9] are handled by designing as you go along: emergent design.

SOLUTION  

Emergent design means that very little time is spent designing the system before coding begins (i.e., there is no BDUF). The overall design and architecture will morph many times in the course of the project. But the lack of significant up-front design is considered safe because the code is being constantly refactored.

SOLUTION  

Constant refactoring (i.e., constant tweaking and simplifying of your design) creates an unnecessary overhead. Outside the XP world, occasional refactoring is welcome, as it is useful to check and improve ( defluff ) your design. Constant refactoring, however, makes no sense, because plenty of structured thought and discussion will have already gone into getting the design right. In fact, constant refactoring makes sense only in the XP world, where the design is made up as you go along; hence, refactoring is necessary to combat emergent entropy.

Constant refactoring is time consuming and involves rewriting existing code that was previously thought to be finished. It could also potentially introduce lots of bugs , as dependent code is broken when you make small insidious changes to your design, but it s considered safe because of extensive unit testing.

start example

We introduce emergent entropy in Chapter 11. Also see the sidebar Constantly Fighting Emergent Entropy in Chapter 13.

end example
 
SOLUTION  

Unit tests are useful in everyday coding (not just in XP). However, as a safety net for test-first design and constant refactoring, they leave a critical area uncovered: design correctness. The problem is that unit tests catch certain types of code-level bugs, but they don t catch wrongness of a design. Design errors really need a human to be involved ” ideally , a full-time person to sit beside you and behave like a design unit tester. Luckily, XP has just such a safety net: the pair programmer.

SOLUTION  

Pair programming enables the programmers to help each other to stumble and fumble through the dark tunnels of scary Castle Complexity. Rotating the pairs frequently prevents -them from becoming stale and helps to increase code familiarity . However, accountability becomes a problem because each programmer ends up working on several different parts of the system in a day. As usual, XP has an answer for this: Nobody is accountable! In other words, everyone owns the code as a collective.

SOLUTION  

Collective ownership is a double-edged snake. On one hand, if everyone is responsible for the entire codebase , then crufty code does not stay crufty for long: Someone will find it and refactor it. On the other hand, collective ownership also means that really, no one is responsible for anything. There s no direct accountability besides the collective team being responsible. The problem of a pair jumping in and changing any piece of code could also be a problem and may result in endless refactoring, where a design is being pulled in two different directions by different programmer pairs. But without a detailed specification of any sort , the code being produced would become increasingly distant from what the customer really wants. So XP gives the team a walking, talking, mind-changing spec, empowered to make snap decisions that can change the course of the whole project: the on-site customer representative.

SOLUTION  

Having an on-site customer representative is risky for a number of reasons, not least that he or she is bound to be pretty junior. Is the customer really going to spare a senior decision-maker for an entire year? (How about for 4 years ”after all, it s an open -ended variable scope contract, right?) Another, probably more important, reason is that the XP customer role is inherently challenging and therefore stressful. As we saw in Chapter 2, it is unlikely that the on-site customer representative will survive the entire project, and this is the person who holds the detailed requirements in his or her head.

Regardless, the customer representative becomes the formalized requirements spec. The presence of the customer on-site also means that the project scope can (and is likely to) change throughout the project. This would be nearly impossible to accurately plan in any detail. But this doesn t matter because planning is just a game anyway. Not to mention that keeping the requirements up-to-date at this rate of change could become a real nightmare. Luckily, XP tells us that we don t need to write the requirements down in any permanent or detailed form.

start example

Also see the section On-site Customer: The Old Testament in Chapter 5.

end example
 
SOLUTION  

Having no detailed written requirements is dangerous because . . . and we re back at the start of the loop. ( There s a hole in my bucket . . . )

We cover the preceding snakes in more detail in the remainder of the book.

start sidebar
VoXP
Voice of eXPerience: Let One Snake Loose, And . . .

This description of an XP project gone badly wrong was given to us by an XPer who understandably wishes to remain anonymous. It s a shining example of XP hitting the mainstream. The team wanted to do all of XP but were prevented from performing all of the practices because management got involved and selectively chose the practices to perform on a spurious economic basis (i.e., Don t do refactoring, it s rework . Do this new work instead. ). The result was, as you can imagine, a mess. We would point out that this is quite an extreme example, but based on information from the various XPers we ve spoken to, the situation doesn t appear to be atypical. Our own comments are added in italics.

The team consisted of about 10 programmers, 5 DBAs/admins, plus a team of 15 analysts. Staff turnover on the project was quite high (particularly among the contractors).

Actually, the most interesting thing was how little of XP that we were doing, even though the company describes itself as an XP shop. The prevailing attitude was, We re doing XP, so don t do any of that up-front design stuff. Just code, code, code. We can refactor it later. Later (where most of the lunacy was driven by management) the attitude was, Refactor? No, no time for that. We ve got all these new features to add!

This brings up the issue that refactoring doesn t get its own story card; it s just supposed to happen all the time as a concurrent process. But in companies where time is scarce , refactoring of existing code may be seen as a luxury.

The codebase was like a small city: huge, sprawling, and unfeasibly complex, with lots and lots of duplication. Sometimes, uncovering buried subsystems was like discovering telephone lines or sewers, then three different sewers because the companies were competing.

This is hardly once and only once, [10] but it s a telltale sign of a project that has been allowed to evolve with no up-front design and no time spent on refactoring.

We deviated from XP in other ways out of necessity. We stored user stories electronically because there were too many people to share a single stack of cards. Even a team of two people would find this a problem. Also, the management couldn t justify optional scope contracts ”we needed to be able to say, Yes, we re going to produce this by this date. We also didn t have a real on-site customer, but we did have a team of analysts in the same building.

(Luckily, XP has shifted its goalposts to make the last one real XP. Goal by default!)

The upshot is that most of the XP practices just can t be justified individually, and that s what happens ”XP rarely appears to be accepted as a whole. It gets adopted piece by piece.

One particular team member championed the cause of unit testing. When she went on holiday, the rest of the team stopped unit testing for a short while (about a week), and it was really noticeable that the code quality suffered almost immediately ”suddenly a lot more defects were springing up. Even though we weren t doing much refactoring, the unit tests were still necessary for regression testing as new functionality was being added.

Further discussion revealed that the reason so many defects were springing up was because the code was so badly factored . The unit tests were just about keeping the snakes at bay, but the code seriously needed to be cleaned up.

We also practiced collective ownership. This caused the problem that there was no accountability ”new contractors joining the team consistently said, [Insert expletive here], who wrote this code? In answer, all the programmers could do was shrug their shoulders, because nobody knew the answer ”no one to fire.

So there wasn t much actual XP going on ”just enough of it to cause a big stinky mess. And the more we look into this, the more it seems that that s how XP gets adopted in the real world. Introduce the risky, hype-inflated practices first (the ones that give management the advertised benefits ), and then plan to introduce the other practices later at some stage maybe, if there s time.

end sidebar
 

And, it seems that XP is especially prone to this failure mechanism precisely because these risky, hype-inflated practices appeal , in many cases, to the wrong types of individuals, including cowboy coders and pointy-haired managers who should know better, but often don t.

[7] Kent Beck, op. cit., p. 63.

[8 ] See http://www.extremeprogramming.org .

[9] We discuss some ways of dealing with vague requirements in a non-XP context in Chapters 10 and 15.

[10] See http://www.c2.com/cgi/wiki?OnceAndOnlyOnce .




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