Extreme Programming Defanged: Taking the Extreme out of XP


Extreme Programming Defanged: Taking the ˜ Extreme out of XP

SOLUTION  

Now that we ve analyzed XP s many flaws and described some of the areas in which an agile process risks being fragile, let s try to put the pieces together into an agile process that s hopefully less prone to these risks.

start example

We provide a brief summary of our refactored process near the end of Chapter 1. Also refer to the Defanged sections at the end of most chapters in this book ”these combined with the process described in this section comprise our defanged, refactored process.

end example
 

Many of the practices that XP promotes can be, and very frequently are, applied successfully to non-XP projects. For example, automated testing is growing in popularity, because it really does help to stabilize code and catch bugs . If you have access to an on-site customer (at least for part of the project), that can have a beneficial effect too. Agile projects are not the only ones that benefit from such practices.

However, lifting these practices out of XP and putting them straight into another project, verbatim, isn t always such a good idea. This is partly because XP puts words like always, frequent, and continuous in front of many of its practices and recommendations.

If you remove the push the dial up to 10 [5] modifiers, many of the practices can be safely applied. But which ones?

We ve divided this section into these two areas:

  • Refactored XP Practices/Xtudes [6] /Values/Tenets

  • Additional Practices

Refactored XP
Practices/Xtudes/Values/Tenets

In this section, we take the existing XP practices, etc. and tweak them (or, in certain cases, completely rewrite them) to provide something that should be suited to a wider range of projects.

The Values

There s absolutely nothing wrong with having a set of values to guide your work, or indeed your life. The four XP values ”communication, simplicity, feedback, and courage ”are worth keeping in mind.

Putting them into practical use is more difficult than simply accepting them as useful high-level guides. Putting the communication value into practice, for example, means actually making an effort to talk to people more (shudder!) ”not just for a few days (like a New Year s resolution), but throughout the project.

start example

We discuss simplicity in Chapter 12 and in the section Example from Extreme Programming Installed : Patient Records Database in Chapter 14.

end example
 

Putting the simplicity value into practice means constantly thinking about how things can be simplified, although the trick is often knowing when to stop.

A prehistoric hunter-gatherer looking for a way to simplify the amount of gear he has to take on a long day s hunt might whittle down his hefty spear until he has a sleek, ultralightweight toothpick that he can carry for miles, but that wouldn t even pick the gunk from between a woolly mammoth s teeth, let alone pierce its tough hide. So simplicity is something of an acquired art that involves not just keeping something simple, but also knowing when to stop and not make it too simple. You ll generally find, however, that it s more challenging to create a simple, elegant solution to a complex problem than it is to create a complex, unwieldy, overdesigned solution. The payoff for making the effort, though, is huge.

The listening value is also important. Eliciting feedback from the customer and from your peers and not being offended when you re criticized are valuable skills. Often you can engender more respect by admitting that you re wrong and giving your colleagues some credit for their own experience and judgment than by blindly insisting that you re right (and possibly leading the project down a blind alley as a result).

We suggest that maybe the courage value should be regarded with bemusement:

Courage is the trademark of Extreme Programming. It is our goal. And, it is the yardstick we should use to judge a project. [7]

Perhaps a more appropriate word would have been confidence. [8] Soldiers and firefighters have courage. Despite this, though, it s useful to have both confidence in your work (and the work of others) and the confidence to make changes should you need to.

The Planning Game

XP s planning game offers some useful advice on structuring an agile project, namely planning ahead at a broad level of detail; dividing the project into very short, fixed iterations; and only deciding what you need for the next iteration. Tracking the project velocity is also a useful aid in estimating the time to perform individual tasks and for steadily improving the accuracy of your estimates (based on feedback for the current project).

Projects that don t use user stories (e.g., they instead use formal requirements or use cases) can similarly break these down into tasks of roughly equivalent size (in terms of the person-days it will take to implement them). Feature-driven development (FDD) takes a similar approach, breaking work into tasks that each take up to 2 weeks to implement.

Measuring project velocity is useful, but it s important not to mistake speed for distance.

start sidebar
Working Within Your Organization

Teams trying to introduce XP into their organization may face resistance because XP requires big changes to the way that the organization works. For example, XP doesn t work particularly well in projects that must deliver a fixed amount of functionality by a certain date. Unfortunately, this is the way that most companies do business. So our refactored process needs to take this into account and be more applicable to fixed-scope contracts.

One way to achieve this is to use a process that helps us to get both the requirements and the design right early, and to produce an architecture and decompose this into subprojects (also known as subsystems in RUP), each of which can then be designed in more detail. This approach helps to produce an accurate estimate of the project s completion date earlier in the project.

start example

Also see the Taking a Goal-Driven Approach sidebar in this chapter.

end example
 
end sidebar
 

Short Iterations

XP recommends iterations even as short as a week (although 2 to 3 weeks is also allowable ). We ve found 1 month to be the ideal iteration size (with working, functional software delivered at the end of each month). This keeps the team focused on delivery and allows the project velocity to be measured over time. Fixed iterations shorter than a month tend to be too distracting.

Having said that, progress should be tracked on a weekly basis. At the start of each week, each programmer is assigned (or signs up for) a set of tasks that s estimated to take 1 week in total. However, there doesn t need to be a releasable, working version of the software at the end of each week [9] ” that s just too disruptive.

Short Iterations

(Sing to the tune of Revolution by The Beatles)

You say you want short iterations
Well, you know
You really shouldn t skip design

You say since you got pair programmers
Well, you know
That everything will come out fine

But when you skip writing your requirements down
You know you re just setting yourself up to look like a clown

Don t ya know it s just XP
All right
All right

You say you like to do refactoring
Well you know
You could do it right the first time

You say you don t need documentation
Well you know
Because the code is the design

You re gonna have code that doesn t smell too great
But you got no schedules so you can t be late

Ya know it s just XP
Shoo be doo bop

All right
Shoo be doo bop
Mm hmm
All right
Shoo be doo bop

Small Releases

At the end of each month, the in-progress product is released internally to the company for user feedback, quality assurance, and tracking purposes. Actual live customer releases should be planned well in advance so that more effort can be put in to make the software releasable at the appropriate time.

Small releases can help your project because you get early feedback regarding-such things as

  • Usability of the system

  • Usefulness of what s there so far

  • Requests for new functionality (which otherwise might not have been discovered until later and could require a big design change)

Small releases also help to mitigate the problem that occurs when the programmer thinks the software is done and says it s done, but on delivery the customer discovers that it s really not done. Small releases catch this sort of problem early.

It s nice work if you can get it, but do bear in mind that for many project leaders , such an arrangement might be impossible. Your customer might have her own stringent acceptance testing procedure, which would make such a short cycle of releases impossible . The nature of the project itself could also make such short iterations and small releases impractical .

As we mentioned in the Short Iterations section, the project velocity should be tracked on a weekly basis, in addition to tracking the requirements that are completed for each monthly release. Interestingly, this allows perceived progress (tasks completed per week) to be compared with the project s actual progress (requirements implemented and released per month). Thus, if the project is spinning ”completing many tasks (which include bug fixes) but not really getting anywhere (i.e., not completing many requirements) ”then this would show up starkly on the project s monthly progress chart.

start example

We discuss some other aspects of planning and small releases (including the problem of a project going into maintenance mode too early) in Chapter 11.

end example
 

Metaphor

Metaphor is not a replacement for architecture or for a decent centralized project glossary (or even better, a domain model that shows at a broad level the relationships between all the real-world objects in the problem space). However, it s definitely worth spending a little time thinking about one or more suitable metaphors to apply to your architecture. Often, this reduces ambiguity; it s surprisingly common for people to interpret the same name or phrase in different ways. Using a common metaphor consistently throughout the project helps to reduce the chances of such mix-ups.

Simple Design

There s nothing more time consuming than coping with an overly complex way of doing things. Code that s overdesigned, has one layer of indirection too many, or involves changes to a multitude of classes and XML files just to add a small field to the database (without really giving you anything back for your pains) is best thrown out or refactored into something simpler (depending how far gone the problem code is).

Better still, don t code this way in the first place. As we describe in Chapter 12 (and in the case study later in this chapter), some time spent architecting and designing the system up front helps you to identify patterns, simplifications , and easier ways of doing things. It s possible to do all this without writing any production code (which you would have had to spend time refactoring until you got to the design that you should have begun with).

Refactoring

Refactoring ”used in the right context ”is a valuable practice, especially as a supplement to detailed up-front design.

We cover refactoring in detail in Chapter 9, so for now we ll just conclude that it s worth keeping the refactoring practice from XP, but constant refactoring (or refactoring to produce an emergent design, doing a little design every day ) should be taken with a hefty dose of salt.

Testing

Should we test? Why, yes!

Automate as much as you possibly can. With testing, this means having unit tests that catch bugs and help to stabilize changes. This is especially useful during regression testing ”if you invest the time to write a comprehensive set of unit tests, you ll thank yourself for it later when you need to quickly make some changes and the customer is waiting for them.

start example

We discuss unit testing in more detail in Chapter 8.

end example
 

If you re using refactoring for its intended purpose (improving the design of existing code) rather than as a means to produce a design from scratch, then you should find that you don t need to rely on unit tests quite as much. Moderation in all things ”it s worth bearing in mind.

Requirements Documentation

XPers create very short user stories (two- or three-line requirements) that are placeholders, or promises, for future conversations with the customer.

We recommend something a little more rigorous : writing the requirements down in detail, up front, and getting them signed off by all the project stakeholders. The commonly associated drawback with this process is that the programmers might spend a few months doing nothing, waiting to be handed a specification (although this strikes us as much less of a price to pay than, say, having the project cancelled because of misunderstandings between individual project stakeholders later).

One way to get around this problem is to start with a short high-level spec and break this into parallel subprojects. The requirements for the subprojects can then be fleshed out in more detail. The programmers should also be spending this time prototyping and designing.

start sidebar
Of Course XP Works ”We re Doing It!

Regarding the paucity of design documentation in XP (and the problems that this creates), a frequent comment made by pro-XPers who have read Matt s The Case Against Extreme Programming article is along the lines of

You ve obviously never worked on a real XP project! If you did, like I do, then you would realize that XPers do create lots of design documentation!

One critic added, 90% of XP teams have a project wiki! This is fine, except that XP actually doesn t recommend that you create lots of design documentation. It recommends that you create just enough ”the problem here being that just enough is entirely subjective , and the Extremo definition of just enough is quite different from ours. So teams that claim that they re doing XP but are also creating and storing lots of design documentation ” and who are also creating all this documentation up front ”aren t really doing XP. At least not in the pure, XP-as-defined-in-the-20-books-on-XP sense.

These are also the people who claim that XP does work because they re doing it, and their projects are succeeding (although, of course we just have to take their word for this. What we never seem to hear about is what happens in the maintenance phase, or what happens if something goes wrong, or why the project is taking so long).

What these people are doing is an adapted version of XP, tailored to the (rather common) local condition [10] that their project needs more documentation than XP prescribes. In fact, their project is closer to an Agile Modeling (built on

XP) project than pure XP. That is, they re doing sufficient design up front to establish an architecture and set a clear direction for the remainder of the project. And they re identifying what documentation is purely transitory (following some analysis technique for getting the design closer to the code) and what documentation should be kept (and therefore kept up-to-date).

end sidebar
 

Colocated Team

Fitting all the programmers (and analysts) into one room helps to reduce communication costs. However, the downside is that the general noise level increases , and people may find it hard to concentrate.

This particular practice is really a judgment call, and it depends to a massive degree on the culture and preferences of your team. With the refactored practices that we discuss in this chapter (particularly the greater emphasis on documentation), the resultant process doesn t rely on having a colocated team ”it s just a nice-to-have .

Pair Programming

Again, we stress moderation in most things. Pair programming is a useful concept: Apply two minds to one thorny problem, and the chances are that a nice, simple solution will emerge. What we ve found over the years is that pair programming happens naturally in just about every project. At some point, one programmer will call another one over, and they ll sit and peruse the same thorny problem together.

Pair Programming Refactored: A Flexible Approach to Pairing

When pair programming happens, let it happen. When it doesn t happen often enough, remind your developers that they are in fact a team, and they should use each other s strengths to their advantage.

However, don t force people to pair program. There s a serious law of diminishing returns. Remember, each person has a fully functional brain at his or her disposal.

The benefit that this flexible approach gives us is that we don t have to use collective ownership. This gives us individual accountability and individual pride in the code that we write (especially in how well it integrates with the rest of the system).

start example

We discuss collective ownership in the section What If Programmers Take Ownership of Code? in Chapter 3.

end example
 
Pair Programming Refactored: Programming and Reviewing Are Different Activities

XP promotes pair programming as a replacement for code reviews, the theory being that two people programming together (one typing, the other talking) is like reviewing all the time. Unfortunately, this misses the point of code reviews, which is that somebody who wasn t involved in the coding reviews the code. The benefit of code reviews is that a fresh pair of eyes can often spot problems that would have been missed by jaded programmers who are immersed in the task. Wood, trees, and all that. [11]

In addition, we ve found that precode design reviews also help immensely to improve the state of the code even before it s written.

So, pair programming is worth salvaging from XP, but not constant pair programming ”and it certainly shouldn t be mandatory!

start example

We discuss the arguments for and against pair programming in Chapter 6.

end example
 

Programmers Do Design

A valuable lesson to emerge from XP is that programming and designing are very closely related ; therefore, it makes sense for the programmers to handle the designing (whether up front or evolutionary).

XP goes further to say that programming is designing (or, the code is the design). However, we still view designing as being at a higher level of abstraction than programming at the code level (this is why up-front design and test-first design are complementary disciplines). Designing is looking at the bigger picture (100 feet above ground level). There is also architecture, which is the 10,000- foot view.

The worst kind of antimethod is having software architects who produce a high-level architecture and then swan away to confuse the people on some other project. Because the architects don t get involved in the implementation of their architecture, there s nothing there to compel them to produce a workable design. Any old rubbish will do (they think).

So, programmers do architecture and design, but they do most of it precode.

Programmers Write Their Own Tests

As in XP, programmers should write their own unit tests. This gets them thinking about code quality, which is definitely a good thing. There should still be a separate tester or testing team, though (in XP, the tester role is adopted by both the programmer [writing unit tests] and the customer [writing acceptance tests]).

Test-First Design Complements Up-Front Design

Up-front design and test-first design are entirely complementary practices, because they tend to address the design at different levels of detail and scope. Consider this paragraph from Agile Modeling (our emphasis):

There is room for conceptual overlap [between Agile Modeling and test-first design] because test-first development clearly delves into the realm of detailed design since it provides developers with an opportunity to think through their code before they write it (as well as important feedback regarding their code). If you ve chosen to do a little modeling before writing your code, perhaps to think through an issue larger than a single test case, then that s okay. In fact, it may even make your test-first development efforts easier, particularly if you have adopted AM s Consider Testability practice. [12]

It s worth emphasizing that Agile Modeling (AM) isn t XP, because it emphasizes models and diagrams (which XP deemphasizes) and up-front modeling (which XP discourages). However, AM provides useful guidance on how to apply these disciplines within an agile context.

To get the bigger architectural picture, begin by creating an overall design, thinking it through, prototyping, drawing on whiteboards , arguing over the best approach, and getting senior engineers involved to incorporate their valuable feedback. This should culminate in an architecture document that will prove invaluable as development proceeds. The project is broken down into smaller areas, each of which has its own detailed design document. Each of these areas may be designed and implemented in parallel.

Taking this approach almost invariably produces a stronger design. Combine this with writing the tests before writing the code and you should end up with well-designed and planned-out code that is eminently testable. [13]

Spikes

The XP spike is a quick, ad hoc prototype, the theory being that if you aren t sure how to code something, you try coding it one way for a day, then try it a different way, and keep the one that least makes your stomach turn .

As we described in Chapter 12, the process that we advocate includes a lot more prototyping than XP, because prototyping code is faster than writing and refactoring production code. Thus, you might find that you just don t need to write spikes once you get to production coding (though spikes can still be useful on occasion). If you find that you ve reached a coding impasse, and you re unsure how to massage some code into the design, then it s time to question the design. Hold a quick review meeting with the team to work out what might have gone wrong and how to integrate the new code into the design.

Note that spikes are also used in XP as a way of exploring how long a particular task is going to take (i.e., they re part of the planning game). In this sense they re similar to the early prototyping technique we describe in Chapter 12, because for this particular purpose they involve preproduction code prototyping.

Continuous Integration

Before keeping this one, we would change it to frequent integration (which in practical terms is what it really means in the XP sense).

start example

See our description of continuous integration in the section Case Study: The Server Tools Project (Using a Defanged, Much Less Extreme but Still Very Agile Process) later in this chapter.

end example
 
start sidebar
Continuous Integration Combined with Test-First Design

When using a dedicated build and test PC, teams that combine continuous integration with a test-first approach may find that the following problem occurs.

Because the tests are written first and deliberately fail, the code can t be integrated until all the tests pass, as the build PC ( assuming it s regularly building the code and running the unit tests once an hour or more) will catch the failed tests very quickly. This might seem like a minor annoyance, but in practice it can start to hinder the team s progress. In XP, this problem is mitigated by breaking the development into smaller steps: Write a few small tests, write the associated code to pass the tests, integrate it, and then rinse and repeat.

However, we found in our Server Tools project (see the case study later in this chapter) that this approach quickly became inefficient, and we had to think creatively a bit too frequently to find ways to write chunks of code of a meaningful size and still integrate often. This became an annoyance because we wanted to spend sufficient time on a piece of code without worrying about making it work just so that it could be integrated within the next 20 minutes.

Instead, we settled on integrating working code at least once a day if feasible and taking slightly longer than a day if needed. This method turned out to be a lot more efficient for us.

end sidebar
 

Sustainable Pace (40-Hour Week)

Working a 40-hour week is good work if you can get it. Of course, that does mean not working the other 40 hours that your boss has penciled you in for. Even for people such as ourselves who live, breathe, sleep computers, you should find that your quality of life improves a whole lot if, more often than not, you give yourself the evening off. You ll find that weekends are wonderful little nuggets of long-lost freedom when you rediscover them. Use the time well: Take your family to the zoo. If you live alone, build a model ship out of matchsticks (we live exciting lives, as you can tell).

You ll probably find that there will be spikes in your working hours ” sometimes, you just have to show some commitment to the company by staying late every now and again to get something finished on time. When deadlines loom, as customers become more concerned , you ll find yourself having to work late again. It s inevitable, but some of us prefer to have it this way than to work at a job that doesn t really matter to us.

The trick is to be able to achieve a consistent, sustainable pace: to work at maximum productivity without burning yourself out (or your team, for that matter). Monthly sprints (as in Scrum ”see the reference at the end of this chapter) help to focus the team and maintain a healthy sense of urgency, as distinct from panic.

On-site Customer

The information you gather for your project s requirements will come from a variety of sources. If you can get a real customer representative to sit in with your team for a large proportion of the project, it s worth doing. However, the system isn t necessarily being written especially for the customer ” specifically , it s being written for the people that will be using the system on a day-to-day basis. As such, the customer shouldn t be your sole source of information; you also need to talk at length with the users, the clerks, the supervisors, and everyone else who can be thought of as a project stakeholder.

What you do need from the customer is the final sign-off ”not from the people-who are telling you what needs to be in the system, but from the person who will be putting your payment check in the mail. In C3 parlance, this would be the gold owner. As C3 has shown us, it s vital to distinguish between the project sponsor and the information providers and to get sign-off from the right one. Always know your true master.

In certain situations, it still makes sense to have a customer representative on-site for some of the time. If that person has some real domain knowledge and has been authorized to make on-the-spot decisions about the scope of the project, then it s worth doing. It s a situation that needs to be handled with care, though. Not all programmers are suited to a customer- facing role. To use an extreme stereotype, imagine an unkempt hacker who hasn t washed his or her hair for several days and has yet to be sold on the idea of deodorant or toothpaste taking your key client out to lunch at the local Burger King.

In most cases, the reality will hopefully be a toned-down version of that scary example. However, asking a key client to sit in with your programmers for any length of time (even if they do wash behind their ears regularly) could be taxing the relationship somewhat. It won t always be this way: Often, the relationship can work very well, and the customer will come out of the deal feeling very good about his level of involvement. The trick is to make a judgment call at the time. Try not to rely on any software process that requires a permanent onsite customer for it to work properly. Life just isn t that straightforward.

Conversely, XP does make the provision for a customer role (we apologize on XP s behalf for introducing such a confusing and misleading role name). The customer role is played by a business analyst who isn t the real customer, but who talks to the customer regularly and is able to act as a customer proxy. Such a person is unlikely to be authorized to make actual decisions regarding project scope (this is particularly true with traditional bespoke projects that have one external customer). In this case, the analyst-customer can still be a hive of information ( Should the system do this or that? This! No, that! ), but in the case where actual decisions need to be made, there would inevitably be a delay while the analyst-customer contacts the mothership for instructions.

Collaborative Coding Standards

Coding standards are definitely worth salvaging from XP. A good standards document will explain up front why coding standards are so important (and what the programmer stands to gain from the deal). With such an arrangement, unequivocal buy-in from the people involved is essential. This isn t something that can be forced; someone who is bullied into doing something against her will is likely to get pretty demotivated. Instead, a team that has provided input into and fully understands the importance of a set of standards will actively conform to them and hopefully provide feedback to help hone and improve the standards even more.

A good standards document will also not just stop at such items as positioning of curly braces, but instead will provide advice about good programming style, best practices, identification of design patterns, and so on.

A good standards document won t encourage the programmer to overcomment his code.

Coding standards are especially important in XP projects, due to the XP practice of collective ownership. If everyone is responsible for all code, then it s doubly important that the code be written in a precise and consistent fashion. The act of doing this isn t such a big thing, but you should be wary of a process that relies on this practice being followed to the letter (especially because diversification ”deviation from standards ”is an almost universal human trait).

The Activities

All four of XP s activities (coding, testing, listening, and designing) are worth keeping. You need to code, you need to test what you ve written, you need to listen, and, of course, you need to design.

start sidebar
Agile Goals, Fragile Practices

Notice that, as we get further from XP s concrete practices and closer to its goals, further into the abstract, we agree more with what XP is trying to achieve. [14] The agile goals of XP are sound ”it s just that the implementation leaves something to be desired. Hence this chapter!

end sidebar
 

Listening, oddly enough, isn t just about listening ”it s also about talking back, asking the right questions, then listening raptly to the answers, assuming nothing (as we describe in the Listening Without Preconceptions sidebar in Chapter 10), and then asking more questions. This is requirements elicitation . The programmers might not have time to do this properly, as they re more interested in getting back to the task in hand, which for them is likely to involve programming. This is why many projects employ a business analyst whose job is solely to elicit requirements from the customer. [15]

These people, if they re good at what they do, will also know how to treat the customer well: take them out to lunch, compliment them on their choice of car, that sort of thing. This is not a dig against programmers (we re programmers ourselves) ”it s simply a statement that different types of people are better suited to different roles. Most business analysts couldn t shake a stick if it involved writing a program, but the chances are that they ll be very good at requirements management and elicitation.

Additional Practices

In this section, we add some practices that have also proven to be extremely useful outside of the documented XP world, but that we ve found (as shown in the case study in the next section) to be a very effective fit with our refactored practices.

Note that some of these tenets are occasionally mentioned in XP and are generally not considered to be incompatible with XP (e.g., a separate QA department).

The Stopgap

Also known as Giving the Customer Something Quickly Without Putting the Project into Maintenance Mode Straightaway. For projects where the customer really needs something up and running very quickly (like within the first month or two), a stopgap release is well worth considering.

This initial version of the product would contain maybe 10% or less of the eventual feature set, and it may not be particularly well designed. In many ways it s similar to XP s initial release, getting useable functionality into the hands of the customer/users early. As such, it should be produced with the same attention to code quality ( extensive unit tests and so on). Something that XP doesn t emphasize (although it doesn t say not to do it) is that the stopgap product should also be run past QA, perhaps even more diligently than the main product (as if that were possible).

What we absolutely need to avoid, though, is putting the project into maintenance mode early. This is one of XP s major shortcomings.

Technical Team Leader

The team leader has greater authority to enforce certain decisions than the XP coach. This sounds dictatorial, but the alternative is the quasi-Marxist regime that we see in XP (which awards more power to the proletariat programmers).

You should find that if your practices are less severe than XP s (and therefore are more easily adhered to over long periods of time), there s less of a need for a full-time coach. Therefore, this role can be safely adopted by the team leader.

Introducing a team leader role can also mean that more time is spent actually programming than discussing the process and how to interpret the Extremos teachings. Discussing how best to proceed is important, but if a roomful of people disagrees emphatically, then at some point it s useful to have someone in a position of authority who can say, Enough! We re doing it this way. Now let s just get on with it.

start example

We compare the team leader role with XP s coach role in the section When XP Starts to Fail in Chapter 14.

end example
 

Quality Assurance

Although QA is deemphasized in XP (because the programmers write their own tests), we feel that a separate QA team is a vital component of software development. QA is a totally different mind-set from programming: QA destroys, programming creates.

A programmer wants his code to work, whereas a QA tester wants it to die ” he actively wants to find bugs, errors, and ugliness. One person just can t wear both hats at once; it creates a major conflict of interest. A QA team member s job is QA: There are no other distractions, no need to fix bugs, and no ego to defend.

QA and programming are different jobs; hence, they should be done by different people.

There s a danger with QA that the programmers can quickly develop a somebody else s problem (SEP) mentality ”that they don t need to test their code because QA will do it for them. As you d probably expect, code quality can drop dramatically as a result. In our refactored process, this danger is balanced by the emphasis on unit tests (as with XP) and individual ownership (unlike XP). If the programmers have to achieve 100% test passes , code quality firmly remains their problem, not somebody else s.

Interaction Designer

HCI design is a fundamental aspect of software development, so it s strange that XP omits a specific interaction designer role.

This problem is mitigated to an extent because XP does promote close involvement with (and early feedback from) the end users, and if the on-site customer can be an actual user, then so much the better. This doesn t take the role far enough, however. An end user will know what she wants when she sees it, but she is unlikely to have the training needed for effective interaction design. So the job of user interface design is left to the programmers, who are really not the right people for the job.

The case for a full-time interaction designer (as a separate role from the programmer, whose goals are in almost direct opposition to interaction design and usability) is made very well in the book The Inmates Are Running the Asylum by Alan Cooper.

start sidebar
Taking a Goal-Driven Approach

When a design is unclear, estimates are sometimes given in ranges, so that the team doesn t unwittingly commit to a deadline it can t hit (e.g., This module will take 3 to 6 days of programming ).

Similarly, at an early stage, functionality can be specified in ranges. This can be achieved by taking a goal-centered approach to specifying the requirements. The high-level goals paint broad brush strokes (e.g., I want a system that combines results from different search engines ). These goals can be steadily broken down into more detailed tasks (e.g., I want to be able to combine search results from Google and AltaVista and I want to be able to sort the results in order of relevance ).

Goals that haven t yet been fully fleshed out with specific details can be easily identified, because they wouldn t have very many tasks identified yet. As soon as sufficient tasks have been identified, then each goal can be estimated more accurately.

This isn t dissimilar to a use case-driven approach, which derives use cases (behavioral requirements ”the tasks ) from higher-level requirements (the goals ). Interaction design also complements this approach rather well.

start example

See Chapter 10 for more about user stories, use cases, and requirements.

end example
 
end sidebar
 

Create Documentation As Part of the Design Process

As we discuss elsewhere, XP attempts to replace the effort that goes into producing design documentation with a combination of collective ownership and oral documentation. This combination of practices has its own special set of problems in an XP project that needs to scale up beyond, say, a roomful of programmers.

For a description of the sorts of problems we mean, see Matt s article Collective Ownership, Oral Documentation, and Scalability: The Perfect Storm at http://www.softwarereality.com/lifecycle/xp/storm.jsp.

As you might have gathered from reading some of the previous chapters in this book, we are in favor of design documentation produced as an integral part of the design process. However, it is worth stressing that design documentation is not a replacement for oral communication . It is still absolutely vital that everyone in the team talk to each other (and not just about football!). Conversely, so-called

oral documentation is not a substitute for written design documentation. Writing something down in an unambiguous way removes ambiguity, funnily enough.

For any project, we don t see written design documents as an optional extra. An added advantage is that not everybody needs to know every aspect of the project s codebase in detail. It still pays for most people to have a broad overview of the architecture and to know as much of the project in detail as possible. For a person to know the entire project isn t always practical, though, particularly with large-scale projects.

So, a less extreme (and, we feel, a more robust and efficient) approach is simply to do the following:

  • Document your design as you design it and keep it up-to-date (this doesn t take as long as some people would have you believe, especially if the documentation is effectively a by-product of the design process).

  • Employ somebody who knows how to design software (many of the problems that XP sets out to solve can in fact be solved magically by employing people who have a clue [16] ).

  • Make sure everyone has a good knowledge of the high-level architecture.

  • Make sure everyone understands the problem domain (in other words, what set of problems is this project setting out to solve).

  • Make sure that each module or subsystem is understood in detail by more than one person.

Individual Ownership

This practice replaces collective ownership, but it certainly isn t mandatory. If collective ownership works well for your team, there s no reason not to continue. However, our refactored process gives you the choice, whereas in XP (as we ve demonstrated elsewhere), there s a Hobson s choice of collective ownership or nothing.

If you do choose individual ownership, the following practices can help to make the process more robust:

  • Encourage people to find out about other parts of the system (but not to spend all day doing it).

  • Promote the assertion that everyone on the team is responsible for overall product quality. This means that if someone finds a defect (whether at the code level or the end user level) in a part of the system she isn t directly involved with, it s her responsibility to log the defect and keep nagging the programmer responsible until the problem is fixed. Each programmer is a deputy of the QA sheriff. Note that this is very different from a programmer going in and fixing someone else s code on his behalf.

start example

See the section What if Programmers Take Ownership of Code? in Chapter 3 for a comparison of collective and individual ownership.

end example
 

[5] This is referring to a quote from Kent Beck in Extreme Programming Explained , in which he states that we should take all these good things and turn the knobs up to 10 ”in other words, do all of them all the time.

[6] See http://c2.com/cgi/wiki?XpXtude.

[7] Chet Hendrickson, When is it not XP? http://www. xprogramming .com/xpmag/NotXP.htm, December 5, 2000.

[8] For an interesting discussion, see http://c2.com/cgi/wiki?XpCourageValue . We can see from this page that the Extremos were originally debating between courage and aggressiveness (not to mention confidence, fearlessness, boldness, and ruthlessness) as a possible name for the value. Our chief weapons are . . .

[9] XP takes the approach that the software should be ready to release at any time, just in case the project is suddenly cancelled. We prefer to take a more realistic approach and plan ahead to specific release milestones.

[10] XP recommends tailoring its practices to local conditions, although (as we describe in Chapter 3) it contains little guidance for doing so, and in many ways tailoring XP can be a risky business.

[11] In XP, collective ownership also helps, in that sooner or later someone else on the team will notice some bad code and refactor it. This is a little too ad hoc, though ”it leaves a lot to chance. A more rigorous approach is to schedule regular reviews (not necessarily with a big group of people, because this can be demoralizing for the person whose code is being analyzed). This coupled with up-front design reviews helps keep your code in shape.

[12] Scott W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (New York, NY: John Wiley & Sons, 2002), p. 188.

[13] For an example of test-first design in practice, see http://www.objectmentor.com/resources/articles/tfd.pdf .

[14] Although we part ways again when XP goes really abstract and ascends into Zen-esque philosophy to justify its practices, as we discuss in the final chapter.

[15] Luckily the Extremos have also seen the light and refactored the XP customer role to mean a team of analysts (as we discuss in Chapter 5).

[16] This may sound blatantly obvious, but that s possibly because it is such basic, profound advice. We re still amazed at the number of projects we see or hear about that contain one or more bad programmers.




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