Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Extreme Programming Explained

Hemos posted more than 14 years ago | from the is-it-like-snowboarding dept.

News 222

While I've been sitting on this for a little while, chromatic has been patient. Yes, it's his review of Kent Beck's Extreme Programming Explained. The publisher is Addison-Wesley, and the book is for all those people out there who need to do programming but don't have time to do the engineering phase. Interesting book - click thru to read more.

The Hook

Want to write better code? How about working less overtime, getting along with your team better, meeting customer demands more quickly and accurately, spending less money, and having more fun?

Extreme Programming may be for you.

Be prepared to make some adjustments and sacrifices. Individual code ownership? Gone. Programming for the future? Slow down, cowboy. Working on your own? Grab a partner and dance.

What's the Scoop?

Extreme Programming is a way to improve software development by focusing on what really matters. If it will cost you $50,000 to implement a feature now that may not be used for two years, and it will cost you $55,000 to implement it in two years, hold off. If running test suites is good, write tests for every significant piece of the system. If multiple pairs of eyes make bugs shallower, program in pairs. If you enjoy meeting deadlines (and not working your fingers to the bone every night for weeks to do so), make shorter deadlines.

It sounds simple, even deceptively so. It may also set your teeth on edge at first.

Imagine that your customer has the time and the manpower to send a representative to sit with your programming team. He is actively involved in the design, writing 'stories' about how the system works for the end users. Every morning and afternoon, your programmers meet to decide which tasks to tackle, and they pair off, sharing one computer between them. One person codes and the other watches, and they switch off as necessary.

With every change to the system, the previous tests are rerun until they work perfectly, and new tests are added to test new functionality. Changes are not commited until all tests run successfully.

Releases are started early (six months, for a big programming project) and continue quickly after that (every couple of months). With a customer sitting in with the programmers, feedback can be instantaneous. The initial investment pays off quickly, while expenses are spread out over a greater period of time.

With no one owning a particular section of code, and with everyone working with different partners from day to day, everyone should have a good overview of the system as a whole. This can lead to better programming, from less bugs to very quick refactoring. New programmers can also be brought in and up to speed much more quickly.

What's to Like?

The book is clear and readable -- even funny. Chapters are short and to the point. Beck uses the metaphor of driving to bring his point across. (Driving is not about pointing in the right direction and maintaining that course, it's about making slight corrections all of the time.)

The bibliography is a great place to find some classic works (including books by Brooks and Knuth and even the movie 'The Princess Bride' -- no, really!).

Extreme Programming itself has a lot of promise. Some of the principles (programming for today, releasing early and often, peer review, community code ownership) fit in pretty well with open source/free software. Some of the other ones would be nice to see....

What Might Annoy You?

It's not clear where Extreme Programming fails. To the author's credit, he mentions this and gives some guidelines, but the choice and the implementation ultimately rest with the managers and bean counters. There will be some resistance at first, but Beck's enthusiasm is infectious and his clarity of explanation might be enough to overcome it.

The Wrapup

If you're a member of or a manager of a moderate programming team, you ought to read this book. It will go nicely on the shelf next to "The Mythical-Man Month". If you're curious about new ways to look at programming (especially in a group), you'll want to pick it up.

Purchase this book at fatbrain.

Table of Contents

  1. The Problem
    1. Risk: The Basic Problem
    2. A Development Episode
    3. Economics of Software Development
    4. Four Variables
    5. Cost of Change
    6. Learning to Drive
    7. Four Values
    8. Basic Principles
    9. Back to Basics
  2. The Solution
    1. Quick Overview
    2. How Could This Work?
    3. Management Strategy
    4. Facilities Strategy
    5. Splitting Business and Technical Responsibility
    6. Planning Strategy
    7. Development Strategy
    8. Design Strategy
    9. Testing Strategy
  3. Implementing XP
    1. Adopting XP
    2. Retrofitting XP
    3. Lifecycle of an Ideal XP Project
    4. Roles for People
    5. 20-80 Rule
    6. What Makes XP Hard
    7. When You Shouldn't Try XP
    8. XP at Work
    9. Conclusion

cancel ×


Sorry! There are no comments related to the filter you selected.


Anonymous Coward | more than 14 years ago | (#1456207)

if($msg =~ /TROLLMASTAH/i) {$reject = 1;}

Recipe for Disaster (0)

panda (10044) | more than 14 years ago | (#1456208)

Sounds like a great way to write non-maintainable code to me. I think I'll pass on this one.

Thanks for the informative review, BTW.

I much rather like sole systems (2)

Rurik (113882) | more than 14 years ago | (#1456209)

Get praise for the work you do right, and be ashamed for your mistakes. Community code, as such, doesn't teach each programmer his mistakes, IMO. If you feel that you have the syntax correct, and convince your partner in that, what if the next day a new pair of coders happen upon it and tear it to pieces. Granted, it was returning null values in the first place, but if the work is already done and posted up, you can look over it, but do you really learn from it?

The way I like it, each person on their own, knowing what to work towards. On routine schedules, a manager(s) will look over everyone's code and test it together. If a problem is found, the manager will discuss it with the coder, and give help on fixing it.
This may be less time effective, but you know that the skills of each programmer are rising, rather than looking at the overall skill of the community (the strong make up for the weak).

end user v. manager feedback (3)

Pfhreakaz0id (82141) | more than 14 years ago | (#1456210)

I like the part about customer feedback (i.e., end user feedback). That is often hard to come by in projects I work on. The tricky part is balancing it with management feedback. A typical situation is one where the users of the software want ultimate flexibility, but management wants software that adheres to certain business rules. As in "you can't set a ship date for whatever you want, it has to be within five weeks of the order date."

BTW, all this is from the perspecitive of "business apps," which some twit said wasn't "real programming" here a while back. Whatever.

Trolling v.s. Flamebait. (0)

Anonymous Coward | more than 14 years ago | (#1456211)

Well, technically speaking a Troll is a posting designed to elicit a particular response from a person or group of people, usually made to show how easily irritable (bitchy) or arrogant th person is. In a classic Troll the perp would post something quite normal, but with either a factual error or an offensice statement in it. The mark would reply to correct or express their outrage, and the perp would either respond with something to defame them (i.e.- you ever stop beating your wife, Mick?) or let the reply stand on it's own if it was a particularly good one. For those interested it comes from th term "trolling for newbies", which itself implies that only an uninitiated would bother responding to correct the troll. Posting to a lightwave discussion group for instance, saying tha the copy of lightwave didn't include the dongle but works anyway, someone would be sure to reply back flaming the person for supporting piracy.

Flamebait, OTOH is a very specialized form of trolling. Basicly the goal is to piss of everyone. There is a fine line between using irony and posting flamebait. This first posing may very well be a troll, however due to the obvious attempt to imflame McDougal. Of course had I still my moderator access I would simply mark it as offtopic because noone else on slashdot really cares.


Anonymous Coward | more than 14 years ago | (#1456212)

> hehehehe, gawd I'm so fucking funny!!

No, no you're not.
Okay, so you feel encouraged by this response? Shame on you.

Re:Recipe for Disaster (1)

Herkemer (331) | more than 14 years ago | (#1456213)

Not really, we've begun using this where I work. If done wrong it's very possible to write horrid code. But if you follow the methodology, especially the pair programming, the constant refactoring and most importantly the testing, then you code ends up in fairly good shape. Not always right out of the box, but over time it improves drastically.

cost? (2)

DGregory (74435) | more than 14 years ago | (#1456214)

With infinite resources anyone can write the most beautiful, bug-free code. I agree that 2 pairs of eyes are better than one, but if they can get that 2nd pair of eyes to go program something else, they can get more programmed in the same amount of time. These are the days of companies being shortstaffed and projects having to be done "yesterday". It all sounds great in theory (just like all the good practices you learn in college C++ class), in the real world, things don't work how you'd ideally like them to.

Ahead of my time (2)

Relic of the Future (118669) | more than 14 years ago | (#1456215)

In highschool, my family got its first computer. My brother and I both were real excited, and we started teaching ourselves QBasic (don't laugh... it's all we had) and we've been programming in pairs ever since. Works incredibly well... much fewer typos, fewer logical mistakes "Hey, what's that for loop s'pose to do?" "This? It's to do the... oh wait, you're right we don't need to do that..."

Now I can't stand to program alone... drives me nuts! I go a lot slower too. Really screwed up my CS grades last year, we were explicitly not allowed to work in pairs on the code :(

"God does not play dice with the universe." -Albert Einstein

Recipe for Success (2)

thanz (102222) | more than 14 years ago | (#1456216)

The 'extreme' moniker is probably just marketing hype. This is isn't really all that 'out there'. This is the way most large consulting firms and code shops work. It may not be the most efficient (or enjoyable) way to develop small apps, but it keeps the pace manageable and the schedule on track for multi-million, multi-year engagements. Specifically, to address the previous poster's comments regarding non-maintainable code: This is in fact one of the best ways to write maintainable code, because everything has has to be documented because everyone has to work on it. No one person owns the code. Again, takes some of the random joy out of coding (no more pink floyd lyrics in the header), but if you're into that, you probably don't work for a consulting firm or a code shop anyway. -thanz

Planning is good! (2)

Woodrow (21174) | more than 14 years ago | (#1456217)

I have flipped through this book at the bookstore and it looks to me as if they initiate a code then analyze/fix methodology. I have no problems with doing this on a project that has flexablity and no deadline. I do have a problem with the idea that you can skip the analysis and design stages of a large complex implementation and just code then go back and fix issues as they come up. Bad habits == bad results. A little planning goes a long way. I have great experience with past projects on this matter. But like I said I only have flipped through the book. Now I have to go buy it and really understand.

Extreme Programming not so extreme (2)

Anonymous Coward | more than 14 years ago | (#1456218)

Maybe my shop is fairly progressive, but I didn't find Beck's techniques to be that revolutionary or controversial.

Bascially, he embraces a hacking mentality instead of rejecting it, and then looks for ways to improve this process through peer review and heavy testing.

As it stands, I think his approach is both good and bad - good in that it doesn't try to turn your world upside down and fore a new methodology on you, but bad in that it seems to deny the usefulness of some valid quality engineering practices.

Sounds Promising (3)

Anonymous Coward | more than 14 years ago | (#1456219)

This method sounds like a programming corollary to the Cabal [] system of design. (The method used to design Half-Life.)

If it's anywhere close to being as effective, it's definitely worth a look.

Pair programming works!!! (2)

Da VinMan (7669) | more than 14 years ago | (#1456220)

I learned about XP (Extreme Programming) a while back and while we don't follow all the practices Beck recommends, the pair programming has worked well for us! This should be obvious to Open Sourcer's since it's just peer review on an immediate level. The real advantage of this for us is that it produces code which is understandable to more than one person, right off the bat. This alone is a good thing. But if you do something devious like pair a programmer with a more knowledgable person, you're also getting some training in. Add to that the fact that more than one person at a time is actively designing the system, and you've got a pretty solid system in place.

This is something I highly recommend that everyone try at work. Only people with huge egos shouldn't bother, but you did remember to check that at the door, right?

What is the "engineering phase"? :) (1)

GoofyBoy (44399) | more than 14 years ago | (#1456221)

>who need to do programming but don't have time to do the engineering phase

Whoa. People have time to do the enginerring phase?!?!?

It's not bad at all (2)

greendot (104457) | more than 14 years ago | (#1456222)

After doing "normal" coding for the past 7 years, I thought I had it down pretty good. We started switching over to "XP" about 12 weeks ago and our company is on it's 2nd project using it. One difference, we split our teams out into 3 week chunks. The teams are small and we work tight. After 6 months of this, each programmer really has a feel for the system and because they work on each piece for 3 weeks, they're not leaving a mess of bugs for the next team. This "XP" thing isn't as bad as it seems. When run side by side with a "normal programming", the XP team always comes in under budget, ahead of schedule, and with fewer bugs. And the constant client feedback on each 3 week iteration is a lot better than the old school "design sessions" and "requirements gathering" phases, which left out a lot of developer/client contact.

It's NOT extreme, just practical (2)

Da VinMan (7669) | more than 14 years ago | (#1456223)

I don't like the name either, it gives managers the willies and makes them think we're going to program their pet project while snowboarding. We just call it "pair programming", makes it sound boring and safe.

"You got that routine done yet?"

"Not yet, got snow in my goggles!"

"OK. hey watch out for that ..."


"...tree." *wince*


Library Coding Tip (2)

Eamonn O'Synan (119195) | more than 14 years ago | (#1456224)

When coding a library, write just those functions you actually need to support the application, and put the tests for that functionality in the test program alongside the library source, which must run successfully before committing the code.

Then, as the functionality develops, watch for factoring opportunities and allow yourself two days to re-factor, running the identical test program successfully to ensure you haven't messed it up.

Every so often, allow four days for a major new-functionality-free re-coding.

This approach gets results quickly and above all allows re-use for the next application with just those extra functions needed being added as required.

Don't spend forever in meetings discussing library design. Let the application drive the libraries and watch as successive application coding efforts get shorter and shorter with greater re-use.

Just my opinion. Flame on.


Extreme programming (1)

VAXGeek (3443) | more than 14 years ago | (#1456225)

Is this like programming on a TRS-80 while bungee jumping?

Moderator (0)

Anonymous Coward | more than 14 years ago | (#1456226)

I am glad you don't have moderator accces.
The first post I saw said that this sounds like a good way to write unmaintainable code.
Working day to day, with constantly changable goals, with no clear plan or design to implement IS a recipe for disaster.
I hope nobody thinks anything but a hack or a prototype should be written this way.

That being said, there is nothing wrong with using prototypes for real work, it is just sloppy (IMNSHO)

Does this book seem to be pushing a BAD idea? (1)

GoofyBoy (44399) | more than 14 years ago | (#1456227)

I could just imagine PHBs reading this book then applying it to EVERY project just to reduce time/costs. Then the code maintance people will have a hell of a time. One of the reasons is that one end-user has no idea what the program act like for a wider group of end-users.

The book also seems to be advocating bad coding. Its what I went to university to learn how not to do.

Re-writing code costs more-do it right 1st time (1)

Da VinMan (7669) | more than 14 years ago | (#1456228)

But if your project has a history of needing to re-write code, pair programming will be cheaper. Guaranteed.

Re:It's not bad at all (1)

Woodrow (21174) | more than 14 years ago | (#1456229)

If you started 12 weeks ago then how could you have 6 months of experience with XP?

Re:Recipe for Disaster (2)

bbutton (90403) | more than 14 years ago | (#1456230)

Why would you say that? Keep in mind that the review only mentioned the briefest description of the practices involved with XP. There are a lot more.

For example, maintainability is maintained through several cooperating practices, the first being PairProgramming. Every line of code is written with two sets of eyes looking at it. There are reasons for this that I won't go into here, but you can find out about them at the URL I mention below. Next, there is the rule about OnceAndOnlyOnce. This says that code can only appear in one place in a system. If you have the urge to replicate some portion of the code, then you are obligated to refactor the system to provide for a single place for that code to live. This above all else serves to create an elegantly designed system. This leads to RefactorMercilessly, UnitTestsFirst, and a few other of the XP practices.

In the end, though, XP-produced systems tend to be exactly what the customer wants (PlanningGame), thoroughly debugged (UnitTestsFirst), and easily maintainable (OnceAndOnlyOnce et al.).

Check out the Extreme Programming Roadmap [] for a thorough discussion of the XP principles, and subscribe to Rational's Object Technology User's Group for a spirited discussion with many of XP's founders.


SkyWriter (12677) | more than 14 years ago | (#1456231)

Finally a breath of freshair!

... (1)

Anonynous Coward (127724) | more than 14 years ago | (#1456232)

This seems like another entry into the backlash trend I'm beginning to notice vs strictly reusable/OO/framework-based programming.

To some degree, this is a welcome backlash. Many OO/reuse-nuts tend to advocate its principles for all projects across the board when many projects aren't helped, and some are in fact hindered by these techniques.

Re:Recipe for Disaster (1)

johnburton (21870) | more than 14 years ago | (#1456233)

No, the whole point is that you make it easier and safer to make changes to the code by having extensive unit tests for example, so that you can afford to make changes to the code to keep it well designed.

Most code starts off well designed and becomes worse over time because either you don't have time to keep the design "clean" when adding new stuff, or because you don't dare to change existing working code to fit in with your new code because you might break it.

This book shows you how to organise things so you don't need to be afraid to change your code and are able to keep it well designed as it evolves.

Spiral rehash? (3)

Mr Neutron (93455) | more than 14 years ago | (#1456234)

This sounds much like the "sprial" lifecycle model, which has been around for some time. Risk management is very important, and with the spiral model you want to identify the risky-but-critical parts of the project and tackle those early. If you can't implement those critical areas, your project isn't going anywhere.

Comments about user feedback are right on the money. Frankly, if you're developing a mission-critical app and you *don't* have constant feedback from the users during development, you're asking for failure. Software engineers aren't domain experts, and we will screw it up we lock ourselves away from the users. Yes, you'll have management constraints but you must always present options to the user. "We can implement the 100% solution using X time/money, or we can give you the 80% solution in X/2 time/money and also have resources to attack Y and Z. You pick."


Re:Does this book seem to be pushing a BAD idea? (1)

Anonynous Coward (127724) | more than 14 years ago | (#1456235)

Turnabout is fair play. Many PHBs have read the extremely optimistic OO/design pattern/reuse books that have proliferated over the past 5 years, and are applying those ideas to EVERY project. Sometimes they just aren't the right tools for the job.

Re:Pair programming works!!! (2)

pieguy (113993) | more than 14 years ago | (#1456236)

Programming in pairs is one way to accomplish something I've believed in for years. Peer review of code is often considered optional. One result of non review is that Junior programmers never get their bad coding practices corrected. I wouldn't be concerned about New Year's except for all the crappy code I've been skipping over as I fix Y2K bugs.

Re:Recipe for Disaster (2)

The Variable Man (116365) | more than 14 years ago | (#1456237)

I had a little chuckle when my brother introduced me to this 'new' concept. I've been working like this for a number of years. The key points to me are:

  • no-one 'owns' their own code
  • peer review early in the cycle
  • test sooner rather than later
  • end user involvement
  • shared responsablity (?)
The words 'open-source' spring to mind...

Re:Planning is good! (3)

devphil (51341) | more than 14 years ago | (#1456238)

There is an excellent interview with the XP creator in some recent issues of _C++ Report_ (which is itself a very respected journal). Some very good questions and answers are brought up by (IIRC) John Vlissides, the interviewer...

...whose last name I just horribly misspelled, probably. :-(

Re:Planning is good! (2)

johnburton (21870) | more than 14 years ago | (#1456239)

You need to read the book.

It's not about skipping the design phase, it's about doing things differently. Don't design things until you need them because the chances are that by that time you'll have either changes the specification or else have thought of a better way.

It's about breaking down a big project into lots of tiny ones where you get a bit of functionallity designed and implemented and working and with automated tests before moving onto the next bit of functionallity. So you always know where you are and how much there is left to do. You always know what you've done so far works because you have tests to prove it. You know that you can easily change what you've done when you need to because you have automated tests which will tell you if anything has broken.

It's very strong on getting requirements and testing your code against those requirements, it just doesn't require a lot of up-front effort that will probably be wasted.

What sets it apart in my opinion from a code/fix methodology is that there are strong customer driven requirements to ensure that you build the right thing, and an emphasis on automated testing so you know that what you build works.

Re:cost? (1)

richieb (3277) | more than 14 years ago | (#1456240)

You assume that two programmers working separately can produce more and of better quality in the same period. This is not necessarily true. Try some experiments....


Re:I much rather like sole systems (2)

pieguy (113993) | more than 14 years ago | (#1456241)

Actually, it works the opposite. Programmers who only work on their own never learn better programming techniques and algorithms beyond what they can think up just by themselves. Also, beginners don't have their bad coding practices corrected if a more knowledgeable programmer doesn't mentor them. The projects where I've worked on teams have always had better results than the projects where everyone worked independently. ---------------------------------------------

Re:Planning is good! (1)

Woodrow (21174) | more than 14 years ago | (#1456242)

Like I said it was my initial reaction to the book. I do plan on reading it more fully. I have others respond as I have to the book and they have read it. Thanks for the reply.

Extreme Programming web site (4)

dsplat (73054) | more than 14 years ago | (#1456243)

I can't believe that no one else has posted a link to the Extreme Programming web site [] yet. A former coworker pointed it out to me. It is worth the time to read. Some of the ideas are excellent. The one I particularly liked which I have seen used by a group I work with is coupling an automated regression test suite with a requirement that all code changes must pass that suite before they can be committed.

Enginerring? (0)

Anonymous Coward | more than 14 years ago | (#1456244)

Ok, I think I know what your problem is: you've been doing "enginerring" instead of doing "engineering"!

But seriously, you need to have some idea of what you're developing before you start coding, just like you need to have some idea of what you're destination is before you set off driving. Otherwise, you don't know whether or not you're moving in the correct direction, to say nothing of knowing when you've reached your destination. Usually proper planning, implementing tools, and testing saves time in the long run.

Too many eyes (3)

dmorin (25609) | more than 14 years ago | (#1456245)

Reminds me of a time back in college when three of us were assigned projects in an AI class. One guy had no experience, so he did nothing. Two of us spent all nighters working on the code. One night, around 4am, our Lisp code wasn't working and we were stuck. We'd stared at it for hours, no luck.

"Wait a second!" shouted my partner, leaning over my shoulder and beginning to type.

"WHAT?" I asked, watching him move the cursor.

He cursored over to a piece of Lisp code, and pressed the space bar. "Sorry," he said, "That was bugging me. Now it's indented properly."

Re:Planning is good! (1)

johnburton (21870) | more than 14 years ago | (#1456246)

I think that you have to be very diciplined indeed to make this work. If you can stick to the principles it's probably a big gain over traditional methodologies. With a poor team, or one that's too big, or that just doesn't stick to the principles I can see how it might fail horribly.

Re:Planning is good! (1)

Woodrow (21174) | more than 14 years ago | (#1456247)

I also wanted to reply to your small issue remark. I also have this same philosophy. I like to call it the Onion development method. Get the "core" implemented/tested/working and then add "layers". After each layer do a full test cycle and verufy that the whole is working.

Re:It's not bad at all (1)

aeonek (73537) | more than 14 years ago | (#1456248)

I think he's hunting for (Score:3, interesting).

Communication and Specification (2)

adimarco (30853) | more than 14 years ago | (#1456249)

One of the things I dream about is detailed specifications.

I used to dread the paperwork and meetings and monotonous never-ending corporate BS involved in "requirements gathering" and the like, but the last several jobs I've done have demonstrated their value beyond any shadow of a doubt.

People don't understand how programmers work, much less the computers they use :) Time and time again the people I write applications for turn out to have no real idea what they're asking for, or how it should work. "uuh, I donno, make it work" really doesn't do much for me as a programmer, which is why the following bit caught my eye:

Imagine that your customer has the time and the manpower to send a representative to sit with your programming team. He is actively involved in the design, writing 'stories' about how the system works for the end users

The jobs that have been done correctly, the ones where you don't spend 1/2 the time "adding features" that should have been included in the initial design specification (requiring changes to the fundamental architecture, blah blah blah), have all included this kind of a buffer between the "client" and the programming team. These are the people that hammer out 80 page requirements documents, which may at first appear to take all the fun out of it, but in fact save a whole lot of work in the long run.

"The Client" always seems to know which "little changes" require you to rewrite the whole application. "Oh, what you've done is *great*, but could you just make this *little change*..." So you have to rework the whole thing from the bottom up, break half of it in the process, and "the client" can't understand why it takes you so long...

Those kinds of headaches can be avoided *only* by getting a detailed specification before you even start...


Re:Planning is good! (1)

Woodrow (21174) | more than 14 years ago | (#1456250)

I do believe that XP has it's place. I really think that it could dominate as a Open Source methodology. Having 5-10 developers and each reviews and can hop around and work on anything. What I find XP failing is that it cannot work with large teams that have specific talents for each individual developer. I like having DBA working on the DB, architects working on the architecture and the UI designers working on the UI. Now group reviews across these subgroups is great and needed. Any thoughts?

Re:Planning is good! (2)

udin (30514) | more than 14 years ago | (#1456251)

The point that Beck makes in the book is not that planning is bad, but that there is little point in planning beyond what your customer knows he wants, especially since customers tend to change their mind. Avoid flexibility overhead where the need for that overhead is entirely speculative. He is opposed to putting in flexibility that may never be used.

Extreme programming is not, however, undisciplined. It requires a commitment on the part of the customer to say what is really important to him, and constant feedback within the development group on task estimation. It is far from 'code then analyze/fix'.

Beck advocates a project management and programming style that can react to changes in requirements quickly: very short task schedules, pair programming, refactoring to keep code clean and to the point, constant testing so that one may make changes with confidence that any errors introduced will immediately be revealed...

I've tried some of this on small personal projects (except the pair part, which is a big except) mostly to become comfortable with the constant testing part and disciplined refactoring, and it is refreshing to not try to anticipate every future eventuality, but instead to try to stay 'to the point' and keep the code clean and simple. In that respect, it is not unlike hacking; the difference is the emphasis on constant detailed testing. This gives you the confidence to rearrange existing code whenever the structure gets shaky. When it does you often find that you can quickly rearrange things in a better way (and it is mostly rearrangement, not new code), test it, and go on your merry way.

In addition to Beck's book, I recommend Fowler's book: "Refactoring: Improving the Design of Existing Code". Taken one at a time, the techniques in this book seem straightforward, even trivial, but as a group go a long way to keeping code in a maintainable, extendible state.

Re:Planning is good! (1)

Woodrow (21174) | more than 14 years ago | (#1456252)

I wanted to stress that I felt that large complex implementation may not be the best test case for XP. I like the whole idea that no one owns the code and everyone has the right to work/review on anything. My problem is that software that can reach 1 million+ lines of code needs to have extensive analysis and design because there is a greater ripple effect when "requirements" change after implementation has started.

Re:Planning is good! (1)

johnburton (21870) | more than 14 years ago | (#1456253)

XP works in fairly short iterations. At the start of each iteration have a planning meeting where tasks for the next iteration are handed out. Your best bet is to pair somebody with database skills with sombody who know little about databases (for a database related task, obviously). That way all of your team will gain a minimum proficiency with all of the code fairly quickly. Perhaps you don't want your user interface designers to become database experts but you'd like them to be at least good enough to fix simple problems with database code.

I would guess that XP does not work well with more than about 10-20 developers partly for the reason you stated, people tend to be more specialised in such an environment. This isn't necessarily a good thing!

Re:Does this book seem to be pushing a BAD idea? (0)

Anonymous Coward | more than 14 years ago | (#1456254)

And how exactly do you think all of this refractoring is going to be done? OO, et al, is a goog way to meet the OnceAndOnlyOnce goal. It is an abstraction mechanism.

XP is engineering level practice - it sets on top of actually programming techniques like OO, procedural, etc. They are not exclusive.

Re:Planning is good! (1)

Woodrow (21174) | more than 14 years ago | (#1456255)

Specialized skills may not be a good thing. Now I agree with you concerning the idea that one should have some knowledge of other disiplines. I think of myself as a UI designer/application developer but I can write my own stored procedures and perform other more simple DB tasks.

So in the end I think we agree on most ideas. Thanks and I am going to get the book and read it. Also take a look at the book "The Pragmatic Programmer" by Hunt, Andrew and Thomas, David. You will get some good ideas from it.

Also look at "The Pragmatic Programmer" book (2)

Woodrow (21174) | more than 14 years ago | (#1456256)

I am reading "The Pragmatic Programmer : From Journeyman to Master" by Hunt, Andrew and Thomas, David and they have many good idea that run parallel to XP. May be a another book someone could review. If needed I can do it if I can find the time.

Re:cost? (2)

pieguy (113993) | more than 14 years ago | (#1456257)

It's typical of the "penny wise; pound foolish" mentality to ignore the benefits part of two eyes and just say the costs are unaffordable. I have often identified coding errors in 30 seconds after someone has worked for three weeks on their own trying to find them. (I have also been on the other end). People who work solo often spend a lot of time figuring something out that someone else already knows.

Where Extreme Programming Fails! (3)

stephend (1735) | more than 14 years ago | (#1456258)

While I can see it working well in a number of circumstances, most of the projects that I've worked on it wouldn't work very well.

Project type 1 where is wouldn't work is any large project, say over fifteen developers (plus management). Any system that big and complex will not be understandable by everyone. Cross-fertilisation is a nice idea, but when things get too complex you need an expert or a keeper.

I guess you could have several experts, but you come up against the cost aspects very quickly.

Project type 2 are those with varying technologies. One I worked on recently used Oracle, Unix, NT, LotusScript (Domino), NotesPump, VBScript, JScript and HTML. I would argue that you can't be an expert in all of them. I do Oracle and Unix and have an appreciation of the others, but I couldn't really add much when I reviewed the work in other teams.

Again you could switch around each team once in a while, but any good team-leader would do that if they could anyway.

And that's before you even get into the 'egoless' bits, and the fact that management like people to be responsible. How can you have a scape-goat if it's everyones fault?!

Anyway, that's enough. Nice idea, but it wouldn't work in real life.

Re:Recipe for Disaster (1)

jormurgandr (128408) | more than 14 years ago | (#1456259)

At first, it sounds like a great idea, but if you actually think about it for more than 5 seconds, it sucks. Rotating programmers throughout a project?? Not only is that going to lead to unmaintainable code, but you'll have programmers working in areas that they know nothing about.
There was never a genius without a tincture of madness.

Test-first seems good, but what about UI? (0)

Anonymous Coward | more than 14 years ago | (#1456260)

I've just finished this book, and a lot of what Beck says makes much sense. I'm starting the coding of an information retrieval framework at the moment and the test-first strategy makes a lot of sense to me. However, how do you do these unit test thingies for User Interface? A lot of the testing theory in XP is based on the assumption that test results are quantifiable (i.e. the 'leave it at 100% testing accuracy so the next team know what broke' stuff) and automated. How do we do this for UI?

Task Difficulty (1)

ucblockhead (63650) | more than 14 years ago | (#1456261)

I've never tried this myself, other than in some debugging tasks. I'm intrigued. However, one question: doesn't this gain you a lot more in "difficult" tasks?

Some of the coding I do is tricky stuff. New technologies. Unusual tasks. Code that needs to be very robust. I can see where this would work wonders. However, some of the coding I do is nothing like that. It is dull stuff, iteration number 5 of stuff I've already done elsewhere. (Code reuse is hard when you change companies!) Basic debugging. Stuff that is really pretty trivial. It seems to me that pair programming would only slow things down in this case.

I suppose it is like everything. You need to learn when to apply it and when it is a waste of time.

Re:What is the "engineering phase"? :) (2)

JordanH (75307) | more than 14 years ago | (#1456262)

  • People have time to do the enginerring phase?!?!?

The problem is that people view engineering as a phase. Engineering should permeate every phase of engineering projects. "Engineering" is not design, but it is an important part of design.

-Jordan Henderson

Re:Extreme Programming web site (1)

Anonymous Coward | more than 14 years ago | (#1456263)

There's actually a site *specifically* devoted to Extreme Programming now, which actually grew out of the site in the post to which I'm replying. The site is: []

Re:Recipe for Disaster (2)

loki7 (11496) | more than 14 years ago | (#1456264)

No, you'll have programmers who understand the whole system. Where I work we shift responsibilities around fairly frequently (although not daily). This means that everyone understands how every part of the project works. And if you know that you're handing your code off to someone else in a few weeks or months you'll write maintainable code. The biggest incentive to write maintainable code is the knowledge that if you don't you're going to piss off your co-worker who takes it over from you.


Today's Buzzword is... (1)

bhurt (1081) | more than 14 years ago | (#1456265)

Gee, we've managed to reinvent code reviews (a weird form, granted, but this is still just code reviews).

"If the feature costs $50,000 to implement today, and $55,000 to implement later when it's needed, implement it later." Well, DUH! It's not the features you expect, it's the features you don't expect which kill you. And this is what seperates a good design from a poor design- a good design can cope with unexpected requirements and features much better.


Save some cash.... (3)

Rombuu (22914) | more than 14 years ago | (#1456266)

This book is available at Amazon for $20.97, instead of the $29.99 Fatbrain wants for it.

If you are so into the whole patent thing, well go ahead and pay more I guess. I just saved 8 bucks, myself.

Re:Extreme Programming not so extreme (0)

Anonymous Coward | more than 14 years ago | (#1456267)

I havn't read this book, and I probably wont buy based on that "skate or die dude" title they're trying to pitch it with. As far as Im concerned, in a few years there is going to be so many dam programmers that the one thing that's going to seperate the big kids from the little kids is going to be the ability to design good reusable sacalable, etc. code. because anyone with a reasonable amount of smarts and determination can code...that's the easy part. So does anyone want me to write a book about how to code in c? I'll call it "programming for slashdotter's" and I'll put in the appendix an IPO HOWTO -'getting rich from nothing' with lots of refereneces to GNU and Linux. RMS will probably boycott me too. I wont waste anyones time.

Re:Where Extreme Programming Fails! (1)

Woodie (8139) | more than 14 years ago | (#1456268)


But, I think the whole point was to make this work on large projects. But, what you really end up doing, is setting very short milestones, and checking early and often. And that actually works pretty well in a number of cases - slap together a framework and use stubs and "mock-ups" and show it to the client frequently.

Basically this is a slight modification on RAD (Rapid Application Design). Which works well - sometimes.

I was involved in a RAD (although I'm not sure it was really "rapid") project for about 1.5 years. We used SQL Server, NT, Lotus Notes, ReplicAction, Replix FAX, VBScript, JScript, and HTML. I worked on all parts of it (a small team of 3 software types), and was the only engineer who managed to stay on board thru the whole thing!

First I started with LotusScript and all the Domino classes, and building forms in Notes. Then, ReplicAction, and SQL stuff was added in, and then we added the FAX stuff, and then I got roped into doing some custom interface work with some OLE DLLs getting Notes to talk to a custom financials system, and then writing HTML pages with ASP to handle reporting on the SQL backend pieces - and launch Crystal Reports web server pages...

I understand all of these technologies very well now. In fact I was (am) the only person who understands all the pieces and how they play together in the particlar context of the system that was built. I only wish that there was someone who would have rotated in, and lightened my load, learned the system...

Re:cost? (0)

Anonymous Coward | more than 14 years ago | (#1456269)

Actually there is an analogy on the XP site. Consider two basketball players shooting into their respective hoops in isolation, fetching the ball, shooting again etc. Then imagine what they can do if they both work the same hoop. One shoots and the other passes it back, sometimes tipping the ball into the hoop if it won't quite make it. Much more fluid.

I'm with you! (2)

DanaL (66515) | more than 14 years ago | (#1456270)

I keep harping on my boss to present a detailed specification to our customers for approval.

While my company does medium sized, database driven websites, I still get frustrated everytime my boss comes back and says, "Oh, the customer thought it was going to do this..."

I don't usually consider work 'coding for fun', because it's nothing like what I work on when I have spare time. It's a job for me, so I like it when it is very clearly stated what it is that the code I write should do.


Re:Extreme Programming web site (0)

Anonymous Coward | more than 14 years ago | (#1456271)

Has anyone seen Tom Christiansen trolling recently? I heard a rumour that he was killed in the Venezuelan floods and I'm urgently looking for confirmation. I will pay $500 for his severed head.

Thank you and Ggod bless all the Tom Christiansen haters of the world.

"Understand the whole system" (2)

seebs (15766) | more than 14 years ago | (#1456272)

That's sort of like what Brooks was arguing about, when he didn't like data hiding.

He changed his mind.

You need an overview of the whole system. Detailed knowledge has a hidden threat - it inclines you to think that the internals of other parts of the system are static, and that you can depend on them.

Re:Save some cash.... (1)

the eric conspiracy (20178) | more than 14 years ago | (#1456273)

Or you could spend $23.50 at bookpool. For $2.50 it's worth tweaking Amazon. Depending on your shipping, you might come out even.

where it fails (3)

dutky (20510) | more than 14 years ago | (#1456274)

I see a some big problems with the technique:
  • no individual code ownership: this seems to suggest that the design would either be imposed from the top, which implies that coders would be treated as unspecialized labor, or that the entire team would be involved in the design of every piece of the code.

    Treating coders as unspecialized labor tends not to work because coders are not like factory workers but more like artisans or craftsmen. When you treat programmers like cattle they tend to resent it and deliver substandard code, at best.

    While getting the entire programming team involved with the design of every piece of the code might sound good, it results in design by committee, which doesn't tend to work in practice. The best designs come from inspired individuals or from very small teams of people.

    Finally, individual code ownership minimizes the need for communication accross the entire group (the N^2 communication problem noted by Brooks in The Mythical Man Month). By requiring a very high degreen of communication between all coders in the group, this technique is almost certain to fail for any group larger than a half dozen or so.
  • new team members: the review asserts that "New programmers can also be brought in and up to speed much more quickly." but doesn't specify how. This is a similar problem to N^2 communication problem and was shown by Brooks to be one of the primary factors in killing large projects. The fact that the reviewer brushes this off so lightly, and that the table of contents doesn't show a chapter specifically dealing with it, suggests to me that it is not addressed.

    Ignoring N^2 communication issues is inexcusable in any methodology postdating The Mythical Man Month.
  • debugging in pairs: debugging in pairs is a good idea, and should be used by any programming team that has the personnel to spare, however, it does not address the central problem of debugging. The problem with debugging is that it tends to take up a huge amount of the project time, and XP seems to want to add even more debugging to the mix (through the use of automated debugging tools). Just pairing your coders during debugging sessions won't reduce the total debugging time very much since it can't increase the number of cases covered or the range of debugging skills present by a significant amount.
  • design to throw one away: The early release schedule seems to imply that the first coded design would be used as the production system. This is not a flaw solely in XP, but is rife in the current programming market. Many systems are built, essentailly, from the initial prototype, with no redesign. Brooks identified this as a problem back in the early seventies, but it doesn't seem to have made much difference to actual practice.

    A methodology that doesn't address the need to redesign the production system, however, will suffer from cost overruns and reliability problems (both of which XP is explicitly trying to avoid) due to the need to work around mistakes and compromises made when designing the prototype.
  • unwarrented assumptions: the review seems full of unreasonable assumptions. Most programming projects don't have the latitude to set prices for each feature, or even to pick and choose which features to implement (at least not after the proposal has been made and the contract accepted). Even if you can set prices for individual features or components of the design, most features will not fall into the easy choice presented in the review. Any feature worth worrying about is likely to have effects across a large part of the design and leaving it out early one will pretty much exclude it later on as well.

    If XP is really dependant on some of these assumptions then it seems unlikely that it is a generally applicable methodology.

So, it sounds a good piece, but I don't see anything that sets it apart from standard practice or from design methodologies that have already been elaborated elsewhere. Some of the ideas are good, but others just seem to be naieve or illconceived: some even seem to smack of outright voodoo software engineering.

Re:It's not bad at all (1)

A Big Gnu Thrush (12795) | more than 14 years ago | (#1456275)

No, he's just making a point. Had he practiced X-Treme /.ing, his "posting partner" would have spotted his egregious mathematical error and corrected it.

Does "posting partner" sound dirty?

Re:Pair programming works!!! (1)

oddjob (58114) | more than 14 years ago | (#1456276)

And junior programmers who never get their bad coding practices corrected become senior programmers who turn projects into hopeless piles of cruft. Peer review is important at all levels.

Re:I'm with you! (2)

adimarco (30853) | more than 14 years ago | (#1456277)

I still get frustrated everytime my boss comes back and says, "Oh, the customer thought it was going to do this..."

Abso-fscking-loutely :) The customer tells you to add a particular piece of functionality, really has no idea what they're talking about, and then complain about it when you add *exactly* what they asked for.

my company does medium sized, database driven websites

Basically what I'm doing right now. The work is essentially cookie-cutter applications (or at least the type we're doing: intranet apps), so the initial time to develop is extremely small. The client is always amazed at first at how fast you're doing it.

It's later, when they "remember" those "few little things" that they want added, and you have to change the database schema in some drastic way 6 months into the project (and thus all your libs, etc. etc.), that they can't understand why it's taking you so long. "You cranked out the first revision in 3 weeks, why'd it take you so long to make that 'little change'?"

It's *impossible* to make them understand why, or why it would have been better to have a detailed specification from the outset.

I think half the problem is that most companies charge a rather hefty fee to produce a "requirements document" (whatever buzzword they're using now). I know mine charges a rather exorbitant fee in the manys of thousands. The client never wants to pay for those kinds of things...


Re:cost? (0)

Anonymous Coward | more than 14 years ago | (#1456278)

I did pair programming (when allowed) in college, and it was an excellent way to do things in a learning environment. But at work, I code on my own but if I have a question or problem I can just go talk to somebody and show them my code. I'm just not too sure yet about having to pair up and work side by side all the time.

Re:Also look at "The Pragmatic Programmer" book (1)

fredb001 (39273) | more than 14 years ago | (#1456279)

Check out

Re:Recipe for Disaster (2)

the eric conspiracy (20178) | more than 14 years ago | (#1456280)

Rotating programmers throughout a project?? Not only is that going to lead to unmaintainable code, but you'll have programmers working in areas that they know nothing about.

Rotating programmers is also very inefficient from a manpower useage point of view. Remember Brook's Mythical Man-Month? As you add people to a task, individual productivity decreases because of communications and learning time. It can get to the point where as you add people to a project, the entire project cycle lengthens.

Each time you rotate a programmer you are going to lose the time he takes coming up to speed. He is also likely to make a lot of mistakes during this period.

Re:"Understand the whole system" (1)

RobertEdwards (15770) | more than 14 years ago | (#1456281)

"Detailed knowledge has a hidden threat - it inclines you to think that the internals of other parts of the system are static, and that you can depend on them."

Which is why Extreme Programming demands NAY DEPENDS on constant regression testing. If you break the build, you get immediate feedback. Structure and defined interfaces are mandatory to make this work.

My question, after reading this is, what OTHER things are needed? There's not a lot of discussion of what you need to impliment XP. Just discussion of things that can go wrong if you don't have them.

Re:Save some cash.... (1)

Anonymous Coward | more than 14 years ago | (#1456282)

spend some of that 8 bucks on a cheap calculator...

Re:Pair programming works!!! (1)

pieguy (113993) | more than 14 years ago | (#1456283)


Another alternative (1)

Esjion (58700) | more than 14 years ago | (#1456284)

If you are doing the whole boycott thing but still want to save a few bucks, you can always try out [] . They are selling it for $23.50 [] , which is more than, but that is unusual - they are typically cheaper than the other online places. I have used several times in the past, and have always been impressed with prices and delivery time.

In this case, the book is out of stock (so you might have to wait a few weeks), but it is a good link to keep in mind the next time you are going to order tech books. All IMHO, of course.

Re:Communication and Specification (2)

richieb (3277) | more than 14 years ago | (#1456285)

One of the things I dream about is detailed specifications.

The only detailed specification that can be trusted is the source code for the system. Any other spec is out of date by the time its printed.

Don't assume that the client really knows what he wants. The system can be designed to be flexible so that adding "little changes" is not a problem.

XP advocates early releases so that the client can use the system and feed back what he learns back to the developers.


Debugging Party (2)

Midnight Ryder (116189) | more than 14 years ago | (#1456286)

It kinda reminds me of an event that took place one day at my house - a debugging party. I was showing off a game I had written, and was getting close to releasing a new version. A couple of my friends hadn't seen it, so, I set down and showed it off to them. I let one of the guys play it, and noticed an area where it slowed down a bit too much...

We spent hours all of us staring at the screen, finding places that the code could have been a little more efficent, etc.

It worked out great, really. I don't think I would want to program like that all the time, but, it's a great way to discuss the code all at once, what the function of a piece of code is, etc. and come up with ways to re-optimize things. I figure before my next release I'll go down to the liquor store and buy some Zima and some beer, and have another debug party :-)

Midnight Ryder []

customer rep sits on his ass (1)

Anonymous Coward | more than 14 years ago | (#1456287)

Chances are that in the first few months of software development this "customer rep" who sits in is going to have absolutely nothing to actually see, so he's just going to annoy everyone. In one of our companies earlier software projects we worked a bit like this - the client was involved way too much. He didn't really understand computers very well. He bickered about silly little things but asked for complicated things ("wouldnt it be nice if we could do x" type of thing). The end result was that he just got in the way too much, slowing down development. His notion of the priorities of the "TODO" list were totally different to that of the developers.

Also "release early and often" in this case seriously hindered progress, since it meant regular demos of the system, and anyone who has been asked during software development to quickly set up a demo will know that this puts a software project back anything from a few days to a few weeks. You hack all sorts of strange things into the code at the last minute to get a demo to look like it works. The code becomes messy and unmaintainable, nobody understands it, lots of bugs creep in, and yet you've still convinced the customer in the demo that things are going well. Lots of the hacked stuff finds its way into your final product.

What we learned from all this is that the customer should only be involved in the design phase and the final phase of software development, with only a handful of "milestone" demos along the way. If you planned your spec properly in the first place then this is normally more than enough to make the small adjustments along the way to make a good product.

I guess I'm skeptical about "extreme programming". I think you can't beat proper planning and system design if you want to minimize costs. If your deadlines are perpetually too close, then you have a management problem, not a technical one, and you should talk to your managers.

Programmers' hours are typically expensive. With a decent system design you can get each programmer to work on his own piece of code, rather than stare at someone else typing. While peer review is valuable, two programmers per station isn't worth it.

"Release early and often" applies well if you are releasing to other programmers, but it is meaningless for commercial clients, since they end up with nothing they can actually use, and they can't give you any useful feedback either. If I go to a restaurant I don't help the chef cook my food, he knows what he is doing. The same applies for software development.

Re:Does this book seem to be pushing a BAD idea? (1)

RobertEdwards (15770) | more than 14 years ago | (#1456288)

"Then the code maintance people will have a hell of a time. One of the reasons is that one end-user has no idea what the program act like for a wider group of end-users."

Actually, I suspect maintance will be easier for the programmers. Since code is constantly evolved during development, much of the critical code will *BE* in maintanace mode for much of the devlopment period.

I'm not sure what you mean about the one end user thing. I suspect a successful LARGE XP project though will require multiple end-user reps on the project team, each representing a different class of users.

Cooper discusses something like this in
"The Inmates are running the Asylum" Perhaps this book would be a good contrast/complement to XPX?

Re:cost? (0)

Anonymous Coward | more than 14 years ago | (#1456289)

Depends on the people. I have worked with pair programming with some people that I could have done the job faster myself. But working with other people who have as much or more experience than me we have produced amazing amounts of quality code in very short periods of time.

Gerald Weinberg: Psycology of Computer Programing (2)

Anonymous Coward | more than 14 years ago | (#1456290)

For some reason this book reminded me of Gerald Weinberg's ancient tomb. Esp the advocacy of very small teams.

I can vouch for the team of 2 while writing code. Never actually seen it used in business (how would the bean counters justify it?), but I used it on some of my hefty college projects (like writing a pascal compiler). Felt that I was never more productive than in school coding as a team of 2. Or perhaps it was that I had a crush on my partner.....

Know there's a concept: Pair a geek guy with a beatiful woman and sit back and watch him try to impress her with his technical prowess (of course it never works, beatiful woman don't care about techy stuff, she'll use him to get promoted/ get an "A" then go out with a jock, but don't tell the geek that he'll create technical marvels in record time)


Keep on keeping on.....

Re:customer rep sits on his ass (1)

RobertEdwards (15770) | more than 14 years ago | (#1456291)

My Idea:

Don't release a demo. Don't do Demos. Screw Demos.

Release the first iteration of code to Production and make the Customer reps teach their peers how to use it.

They'll get so much dang feedback the next couple of iterations will improve things rapidly.

Repeat until nobody feels likes spending time and money on the project.

Extreme Programming! (1)

SydBarrett (65592) | more than 14 years ago | (#1456292)

Coming soon to ESPN2:

SEE: some guy sitting in a dark room in front of a console, typing REALLY FAST!

SEE: The most extreme, hardcore debugging EVER shown on cable!

SEE: One-handed Altair 8800 Programming!

SEE: Guys drinking lots of coffee and haggling over database design!

SEE: Client-Server Action that will blow you away!

(By the way, has anybody ever had a beverage called "Mountain Lighting"?, You can only get it from Wal-Mart, and it's basicly liquid crack)

Re:Library Coding Tip (1)

BeanThere (28381) | more than 14 years ago | (#1456293)

"Don't spend forever in meetings discussing library design. Let the application drive the libraries and watch as successive application coding efforts get shorter and shorter with greater re-use"

I can't see how this can work. Say you have a smallish team of say half a dozen programmers, working on a single set of libraries, and several applications. Application 1 requires some functions to work in a certain way. Then programmer 2 from another application decides that his app needs those functions to work somewhat differently. Either he changes your functions or he adds new similar-but-different functions. Then do this for n programmers and m applications. What you end up with is a mess - multiple stupid functions instead of one decent function, newcomers have no idea which functions do what, there is no single coherent document or specification for anyone to learn what is going on. Programmers make little changes in a library that make their app work, but break others. "Copy-n-paste" becomes a method of "code reuse", since various shared functions weren't put where they belong in the beginning. "Let the application drive the libraries" becomes more like "lets hack functions into the libraries as soon as apps need them". Nobody has a good idea of the overall layout of the system, and nobody knows what everyone else is doing.

This cannot work without a single, decent specification that was planned in one of those boring library design meetings.

[OFFTOPIC] Re:Moderator (1)

El Volio (40489) | more than 14 years ago | (#1456294)

Go back and look. The first post you read is not necessarily the first post made to this story (check the # next to the timestamp of the post itself). Depending on how you have your preferences, the first post could actually be the last one you read, or somewhere in the middle.

This dude sounds to me like one of the better moderators, when he has points.

Re:I much rather like sole systems (2)

sjames (1099) | more than 14 years ago | (#1456295)

The way I like it, each person on their own, knowing what to work towards.

Personally, I like a sort of hybred system. Each person works on his own subsystem as you say, and periodically, programmers review each other's code. Those reviews need to be frequent near the beginning when interfaces are being established. That is a good time to verify correct interpretations, and possably to identify design flaws or inefficiencies befor things get too far along.

It is also useful to sub-divide a large project so that each person gets SEVERAL pieces to work on. That way, it's not so painful to re-apportion later in the project when the time estimates have some real world feedback.

Re:Planning is good! (0)

Anonymous Coward | more than 14 years ago | (#1456296)

It is important to break large programs like this up into layers with well documented programming interfaces.

This allows you to write regression testing for each layer to ensure that the changes that you make don't break anything.

Writing a million line program as a single module is a sure way to write something that is totally unmaintainable.

Another reason that you should write your code in layers is that it becomes easier to break your program up into smaller chunks and run the individual programs as seperate threads or even as seperate processes running on multiple boxes.

Re:Extreme Programming web site (1)

questor (960) | more than 14 years ago | (#1456297)

Another site is ExtremeProgrammingRoadmap [] . This is a "WikiWikiWeb" site, where every page can be edited by anybody, and new pages and links spring into existance automagically just by RunningCapitalizedWordsTogether. This site also covers pattern languages, java idioms, and other semi-related topics...

Re:Communication and Specification (1)

panda (10044) | more than 14 years ago | (#1456298)

The only detailed specification that can be trusted is the source code for the system. Any other spec is out of date by the time its printed.

That may very well be, but when you're starting on a project from scratch. You have to have something to work with. You can't start from nothing, or are you Yuri Geller?

Don't assume that the client really knows what he wants. The system can be designed to be flexible so that adding "little changes" is not a problem.

XP advocates early releases so that the client can use the system and feed back what he learns back to the developers.

Isn't that just wonderful, more headaches. I see this all too often. This is why one should insist on good, complete specifications. Have the customer sign the specs and an agreement to have the work done. When they come back with "little changes," the answer ought to be: You've agreed to this specification. You will be shipped this product. Any changes to the product will be made as enhancements to the already shipped product, and will be specified, estimated, and billed accordingly.

The key to making any project work, and this is not unique to XP, is having the customer involved and available during development, so that they may answer the developers' questions.

I'm also tired of bosses who short change my estimates (by as much as 50%) or who give estimates on work I'm going to do without even consulting me on the time. Then, they bitch when something goes over their estimate (even when it's still within mine). But that's another subject entirely.

Re:Recipe for Disaster (1)

mayoff (29924) | more than 14 years ago | (#1456299)

XP makes a trade-off: for every module, you have a bunch of people who know the code (ideally every programmer on the project). So no one is a bottleneck.

If you have individual code ownership, then when the person who owns module A is busy, no changes can be made to module A. The owner becomes a bottleneck.

Other XP practices lessen the impact of moving programmers around: pair programming, programming standards, unit tests, refactoring.

A personal experience... (3)

William Tanksley (1752) | more than 14 years ago | (#1456300)

A foundational part of XP is the mutability of code: you write the code for what you know now, and be willing in the future to totally change it. One of the best technical books I've read recently discusses the how-tos of this: "Refactoring [] " (by the way, the link directs you to a price comparison site which I find REALLY useful).

I tried to use this method is my latest project, a test framework, and I was extremely pleased by the results; not only did the design morph as I discovered the requirements (so the final result was a design I was pleased with), but the final result snapped into place around the item being tested and no bugs have been discovered in it!

I can highly recommend at least that part of XP: refactoring and coding for today. I'm going to try some of the other parts in small bits at a time, but from what I see they look very useful.

I certainly wouldn't describe XP as being for someone who doesn't have time to design; I would describe it as something for someone who doesn't expect to get it right the first time, and who wants to get it right anyhow. I would also describe it as being for someone who wants to be useful to customers without hurting his own productivity -- see the Bill of rights [] on the Extreme Programming website. In short, XP is about never having to tell a customer that you can't make that change now -- and it's also about always being able to make changes when you need to.


Re:I much rather like sole systems (1)

Phouk (118940) | more than 14 years ago | (#1456301)

In a XP context, personal learning is enhanced because of instantaneous feedback:
  1. Feedback from your partner (bugs are shallower...)
  2. Feedback from the Unit tests.
  3. Feedback from the code ("Code-Smells"), at least if you refactor continously XP-style.

Re:customer rep sits on his ass (0)

Anonymous Coward | more than 14 years ago | (#1456302)

His notion of the priorities of the "TODO" list were totally different to that of the developers.

Ummm...maybe the developers were wrong. The client is the one who's going to use it, right? I work on a very complex web application (really a client-server database app that happens to run on http). We talked to the clients, got some basic functionality running and opened it up to them, and have been modifying it ever since. It is a far better application than it would have been if the actual users had not been involved early and often.

Comparison shop (was: Save some cash....) (2)

RocketJeff (46275) | more than 14 years ago | (#1456303)

I've been using Best Book Buys [] for a few weeks. It looks at quite a few online book stores and shows you the prices (including shipping and availability).

Prices for this book range from $23.92 ( - out of stock) to $33.90 ( (both are UPS ground prices).

It's saved me a few dollars, now and then.


Re:... (1)

staplin (78853) | more than 14 years ago | (#1456304)

I agree that sometimes the OO reuse-nuts go too far. "Why did you use this complicated design?" "Because we could fit in a Factory pattern *and* a Composition pattern!" There are times when a simple answer is better than the most abstracted, most reuseable answer... and there are many times you just don't have the time to code in all the things you could.

On the other hand, even when you're hacking out code, you can identify reuse and more OO like fragments that can save you time and effort.

The seemingly more realistic approach is a blend of OO/reuse where it helps, and when you have the time, but also to leave room for "do what you have to to make it work" kinds of coding.

In either case, you still need to have some form of design, not necessarily a strict one, but somethign to keep you on track. I've seen some really ugly code "evolve" from poorly designed systems.

Re:Where Extreme Programming Fails! (2)

William Tanksley (1752) | more than 14 years ago | (#1456305)

You claim that you've identified an area where it wouldn't work. Now go to the XP site, and observe what project it was originally used in -- a huge, multi-technological one.

I don't think this one's a problem.

Your other objections are also pretty transparent -- they're all of the nature "That's not how we do things here! It's impossible!". Indeed, if management cops that attitude you can't do XP -- but it's an attitude problem, nothing more.


Have the scoffers actually tried coding like this? (3)

vivarin (106778) | more than 14 years ago | (#1456306)

I have, and it works beautifully. In fact, the nastier and more complex the coding problem the better. Two people watching pointer arithmetic are always more careful than one.

That said, a few commonsense caveats must precede its adoption. Namely:

  • Management must allow it
  • If coders are of wildly differing skill levels, then they shouldn't be paired for long periods of time or swaths of code
  • For shorter sections, an individual can take a "first cut" at coding something while somebody else tracks him with test code. Then there should be a trade off and review period.

I know of no piece of code that I've written this way that hasn't been FAR less expensive than its more traditionally coded counterparts, once debugging and QA expenses are factored in. The interesting part is that design and refactoring remain part of the process long after they would normally, as ones assumptions must be continually re-examined as people new to the code come in.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>