Slashdot

Extreme Programming Explained

Posted by Hemos on Tuesday December 21, @09:10AM
from the is-it-like-snowboarding dept.
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.

Title:Extreme Programming Explained
author	Kent Beck
publisher	Addison Wesley, 09/1999
ISBN	0201616416
pages	179
rating	7/10
summary	Extreme Programming Explained explains the virtues of the Extreme Programmer and shows you how to develop them.
reviewer	chromatic

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
   10. Quick Overview
   11. How Could This Work?
   12. Management Strategy
   13. Facilities Strategy
   14. Splitting Business and Technical Responsibility
   15. Planning Strategy
   16. Development Strategy
   17. Design Strategy
   18. Testing Strategy
3. Implementing XP
   19. Adopting XP
   20. Retrofitting XP
   21. Lifecycle of an Ideal XP Project
   22. Roles for People
   23. 20-80 Rule
   24. What Makes XP Hard
   25. When You Shouldn't Try XP
   26. XP at Work
   27. Conclusion

   <  Outdoor Computer Cases? | Tales From The Bazaar  >

    

   Slashdot Login

   Nickname: Password: Don't have an account yet? Go Create One. A user account will allow you to customize all these nutty little boxes, tailor the stories you see, as well as remember your comment viewing preferences.

   Related Links

   fatbrain Table of Contents chromatic More on News Also by Hemos

   Book Reviews

   Jon Katz, Resident Gasbag, has a new, very appropriate book coming out soon, Geeks. Preorder now and receive the book early. For probably the best fiction read around, check out Neal Stephenson's Cryptonomicon, an engaging read about WWII, cryptography and buried treasure. And data vaults. If you've been doing a lot of work in Perl, you've probably figured out you really need Perl in a Nutshell or The Perl Cookbook. If you're still learning, grab Programming Perl. And if you want to learn more about how to become a better coder, grab The Unified Software Development Process or The Practice of Programming Additionally, check out Refactoring: Improving the Design of Existing Code . Developing a large application? Grab Eric Greenberg's excellent Network Application Frameworks. Visit Our Book Reviews Section for more. Update: 11/12 05:19 by H:

   This discussion has been archived. No new comments can be posted.

   Recipe for Disaster (Score:0, Flamebait) by panda on Tuesday December 21, @09:15AM EST (#5) (User Info) http://jason.stephenson.net/

   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.

   Re:Recipe for Disaster (Score:1) by Herkemer on Tuesday December 21, @09:27AM EST (#11) (User Info)

   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.

   Recipe for Success (Score:2, Informative) by thanz (seeker999@hotmail.com) on Tuesday December 21, @09:29AM EST (#14) (User Info)

   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 VERY LOW SODIUM

   It's NOT extreme, just practical (Score:2, Funny) by Da VinMan (VincePlatt@yahoo.com) on Tuesday December 21, @09:39AM EST (#21) (User Info)

   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 ..." *aiiiieeee* "...tree." *wince* :+>

   Pink Floyd lyrics in the headers (Score:1) by lfd on Tuesday December 21, @03:14PM EST (#153) (User Info)

   that would be: So, so you think you can tell heaven from hell, blue sky from pain. Can you tell a green field from a cold steel rail? from "Wish You Were Here," of course ;) -- Going on means going far, going far means returning. Tao te Ching

   Re:Recipe for Success (Score:1) by gstamp (glen_stampoultzis at ansett.com.au) on Tuesday December 21, @05:08PM EST (#162) (User Info)

   ...because everything has to be documented because everyone has to work on it... This doesn't sound like XP to me. XP has very few official documents that it keeps. It uses cards extensively but these are not kept as official documentation. To a large extent the XP treats the code as the documentation. This is not as bad as it sounds because there is a lot of emphasis on making the code as readable as possible. Pair programming and refactoring are designed to help here. XP has the following characteristics: It deals rapidly with a changing environment. Done right it produces very clear code It avoids over-engineering code. It makes programming fun! It increases quality through testing. It increases communication (both with the customer and among team members).

   Re:Recipe for Disaster (Score:2, Informative) by bbutton on Tuesday December 21, @09:46AM EST (#28) (User Info)

   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.

   Re:Recipe for Disaster (Score:1) by johnburton (johnb.sd@jbmail.com) on Tuesday December 21, @09:52AM EST (#31) (User Info) http://www.jbmail.com/

   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.

   Re:Recipe for Disaster (Score:2, Interesting) by The Variable Man on Tuesday December 21, @09:57AM EST (#35) (User Info)

   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:Recipe for Disaster (Score:1) by RalphEJohnson on Tuesday December 21, @09:56PM EST (#176) (User Info)

   XP is similar to how most open-source projects are run, but it is extreme. Is peer review good? Review all designs as they are invented, and review all code as it is typed. Is early testing good? Never write any code unless you already have a test for it. Is end user involvement good? Have a user share the office with the developers. None of the ideas in XP are completely new, but many of them are not often practiced, and what is new about XP is the way that these ideas are defended as good. There is a lot more literature claiming that up-front design is good than there is saying that "you aren't going to need it".

   Re:Recipe for Disaster (Score:1) by jormurgandr on Tuesday December 21, @10:33AM EST (#57) (User Info)

   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. - Aristotle

   Re:Recipe for Disaster (Score:2) by loki7 (peter@quux.net) on Tuesday December 21, @10:42AM EST (#62) (User Info) http://www.quux.net/peter

   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. /peter

   "Understand the whole system" (Score:2) by seebs (seebs@plethora.net) on Tuesday December 21, @11:00AM EST (#70) (User Info) http://www.plethora.net/~seebs/

   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. http://mail-abuse.org/rbl/ - kills spammers dead http://www.alladvantage.com/go.asp?refid=GZX636 - Get paid to surf

   Re:"Understand the whole system" (Score:1) by RobertEdwards on Tuesday December 21, @11:11AM EST (#79) (User Info) http://www.nashville.com/~robert.edwards/index.htm

   "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:Recipe for Disaster (Score:2, Informative) by David Kennedy on Wednesday December 22, @03:42AM EST (#190) (User Info)

   "No, you'll have programmers who understand the whole system" You will? I've been in my current job for 14 months, and I still don't even understand my own subsystem (40+K of C++ involved with network management systems and multiplexers). The whole system here is just under a MLOC of complex code. (Okay, so it's legacy, but aren't most systems? Especially those where you need to turn things on their heads to meet new pressures) We rotate staff frequently, in 14 months we've had 13 people leave (mostly internal transfers). That's bad for a team which has about 7 developers (plus 3 integration/test people). Swapping people doesn't work. Learning time soaks up any and all advantage in bringing in even highly experienced people. Aside from that much of the XP rules are okay, but not shockingly novel. I've been pair programming and constantly peer reviewing for months, it helps, but the single most important thing on a big project isn't mentioned in the XP book (skimmed it only so far) - source control.

   Re:Recipe for Disaster (Score:1) by alan_knight on Wednesday December 22, @04:53PM EST (#204) (User Info) http://www.objectpeople.com

   It's interesting that source control is hardly mentioned, but I think that's because it's a given. Certainly it would be very difficult to practice continuous integration if you didn't have a very solid handle on what you're integrating against. That's certainly the case on the XP projects that I know of, that strong source code control is basic. Clearly, high turnover is a problem for any project, but surely it's better to have most of the people on the team at least have some understanding of the whole system rather than have it confined to few individuals. By doing things in pairs you minimize the risk that one of the people who understood why something was done will be gone in 3 months. By having rigorous and exhaustive tests you provide something that explains in code (the only way that counts) what something is supposed to do, and you ensure that changes by people with incomplete knowledge don't break things.

   Re:Recipe for Disaster (Score:2) by the eric conspiracy (rlarson-at-monmouth-dot-com by-the-sea) on Tuesday December 21, @11:09AM EST (#78) (User Info)

   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. This .sig no verb.

   Re:Recipe for Disaster (Score:1) by mayoff (mayoffslashdot@dqd.com) on Tuesday December 21, @11:50AM EST (#97) (User Info)

   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.

   Re:Recipe for Disaster (Score:1) by darkscanner on Tuesday December 21, @01:45PM EST (#135) (User Info)

   >> Rotating programmers is also very inefficient... Disagree. The benefits of forcing everyone to expand their domain knowledge and have a better overview of the system far outweigh the communication and ramp-up obstacles. In the real world, a programmer quits on the average of every sixteen months. If that individual "owns" lots of code that others are not familiar with, the costs are enormous. It happens all the time. Rotating responsibilities is just one idea that has immense value outside of general XP practice.

   Re:Recipe for Disaster (Score:2, Informative) by the eric conspiracy (rlarson-at-monmouth-dot-com by-the-sea) on Tuesday December 21, @08:09PM EST (#173) (User Info)

   The benefits of forcing everyone to expand their domain knowledge and have a better overview of the system far outweigh the communication and ramp-up obstacles. In the real world, a programmer quits on the average of every sixteen months. If that individual "owns" lots of code that others are not familiar with, the costs are enormous. It happens all the time. Given that the average tenure is so short, teaching other people the code is still a waste of time because they too will be gone in 16 months. When everyone is gone, what do you have? Code and the documentation. Except under Extreme Programming the code is built ad-hoc, and the documentation is non-existent. In addition if you read Brooks, he had a rather different view of the programming process. It is very well known that GOOD programmers are as much as 1000 times more productive than average programmers. Brooks's methods were designed to take maximal advantage of the talent of the top programmer, rather than this pair-programming idea which seems to me designed to achieve least-common denominator code quality. Rotating responsibilities is just one idea that has immense value outside of general XP practice. I've worked in rotationg responsibility environments, in technical organizations outside the computer industry. Do you know what happens? Nobody is in a job long enough to become really proficient. This .sig no verb.

   How adverse to change are you? (Score:1) by GBSW on Tuesday December 21, @01:15PM EST (#124) (User Info)

   Having practiced XP, it is similar to most methodologies in relation to the project triangle and other high-level management approaches. Its implementation, however, is where it significantly diverges. Anyone who throws up their arms and runs away at the ideas is simply adverse to change. Kent has some intriguing ideas that we have successfully implemented and a few new ideas on arbitrary approaches that I've always had problems with (i.e. one person estimating other peoples time, redefinition of the users requirements). The reviewer glosses over numerous key features to XP, such as story-writing, prototyping, and most importantly, pair programming, which is the key to XP. Pair programming is a cultural shift and is difficult to introduce simply because everyone wants their own "space". What you find; however, is with the proper environment, pair programming is quite natural and each of us has experienced it successfully in one way or another. You simply provide the developer with a place for them to go to to make their private calls or spend some time contemplating. Finally, XP only works in some environments. It's approach to modelling and testing doesn't work very well with UI-heavy products. You can only achieve automated testing in approx. 65 to 70% of the UI system (assuming a proper 3-tiered system and that the model represents the data and is not integrated with the UI) and ultimately have to resort to manually testing the GUI.

   Re:Recipe for Disaster (Score:0) by Anonymous Coward on Tuesday December 21, @10:42PM EST (#181)

   My wife and I collaborated on a coding project using the tag-team metaphor. The coding went surprisingly quick (7 weeks), the result, very robust, the upshot -- 4 months in production with no crashes, lost data, or user complaints. We just did it, but now that I think about it, the programs I've worked on that yielded the most bang for the buck in the shortest time used pairs of coders. It could be the communication phenomenon. Trying to keep three or more people in synch requires a lot of communication that becomes "slow" when decisions have to be made. This is especially true when the communications channels are asynchronous. I actually modeled this for a course once. The professor had set us up in 3 and 4 person "e-mail" groups. I demonstrated mathematically that a 4 person group could not actually do any useful work within the time-frame he had specified (he subsequently reduced the groups to 3, then 2). The "rule of thumb" from a coder working on the System 7 code was "a communication event" per line of code (and this can be as trivial as a water-cooler comment). Add in a third person and the "communication overhead" is double that of a pair. I'm buying this -- elarson

   Re:Recipe for Disaster (Score:1) by TimoT on Wednesday December 22, @01:50AM EST (#185) (User Info)

   Sounds like a great way to write non-maintainable code to me. I think I'll pass on this one. Ever heard of RefactorMercilessly and DoTheSimplestThi ngThatCouldPossiblyWork ? These two together should lead to maintainable code, because XP states that anything that isn't written well should be improved on immediately and the unit testing ensures that the changes are correct. This methodology is probably best suited for development of smallish apps in dynamic languages like Lisp and Smalltalk, where the cost of change is small. Interesting, but not as extreme as the name leads you to believe. Personally I like the ideas. For some reason big processes like the RUP seem to get in the way of concentrating on the task. Something small, elegant and adaptive probably works better, IMO. At least for small groups of specialists (like games development, etc.). I wonder if there's any methodologist working on processes for Open Source development over the net ? IMO there's a serious need for research in this area... -- Timo

   I much rather like sole systems (Score:2, Interesting) by Rurik (beb@s-pam.freewwweb.com) on Tuesday December 21, @09:22AM EST (#7) (User Info)

   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).

   Re:I much rather like sole systems (Score:2, Interesting) by pieguy on Tuesday December 21, @10:03AM EST (#39) (User Info)

   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. --------------------------------------------- ------------------------------------ Your perception that I am alien is partly correct. My Father was Human.

   Re:I much rather like sole systems (Score:2) by sjames (sjames@nospam.gdex.net) on Tuesday December 21, @11:44AM EST (#93) (User Info) http://www.members.gdex.net/sjames

   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:I much rather like sole systems (Score:1) by Phouk on Tuesday December 21, @12:05PM EST (#99) (User Info)

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

   Re:I much rather like sole systems (Score:2, Insightful) by samantha (samantha@isis.aurinia.com) on Tuesday December 21, @12:22PM EST (#107) (User Info)

   I agree two pairs of eyes are better than one in code reviews, walkthroughs, debugging sessions and such. I emphatically do not agree that two pairs are better at design and code construction time. Program construction is NOT a team sport in my 20 years of experience and it is damn frustrating when management takes it into their pointy little heads to make it such. May as well do tag team symphony writing or fine art. I especially resent and am fed up with management notions of design by committee. I've wasted months in such attempts to "get consensus". It does not work. Let those who have notions of how to design a subsystem go do so and then review it. Don't try to review it while it is still a bunch of abstractions everyone would like to stick a ego-tag or two into.

   Re:I much rather like sole systems (Score:1) by wildcoder on Tuesday December 21, @01:01PM EST (#119) (User Info)

   Right on! Programming design is a very much individual creative process. Throwing more people in it just cause more problem. I can't count how many times to get conceited but clueless idiots to agree on some simple design decision. Design by committee always cause feature bloated, complicated model, stupid decision, and frustrated people. You just can't believe how many people are pretty clueless about software design.

   Re:I much rather like sole systems (Score:1) by DonWells on Thursday December 23, @09:17AM EST (#205) (User Info)

   When you find yourself describing your team members as "conceited but clueless idiots" it may be time to change the way you work. Instead of working against each other try working together.

   Re:I much rather like sole systems (Score:1) by pieguy on Tuesday December 21, @01:08PM EST (#120) (User Info)

   Yes...I agree that when you're actually cutting code, you do not need someone hanging over your shoulder. The design by committee is not necessarily bad. Usually, when it fails, it's because someone has a big ego or a different agenda (such as showing how commanding a leader he or she is). I'm very familiar with having a good idea shot down merely because some Alpha gorilla wanted to demonstrate they were the biggest guy on the block. ------------------------------------ Your perception that I am alien is partly correct. My Father was Human.

   Re:I much rather like sole systems (Score:1) by DonWells on Thursday December 23, @09:20AM EST (#206) (User Info)

   What if instead of "someone hanging over your shoulder" you had a patner every bit as capable as yourself helping you every step of the way?

   Re:I much rather like sole systems (Score:1) by DonWells on Thursday December 23, @09:29AM EST (#207) (User Info)

   In my 22 years of experience I have found that programming is more and more a team sport every year. Yes, there was a time when lone cowboy coders wrote programmers and were not expected to interact with the other cowboys. Those days are gone forever. To get a reasonable software product to market or into the user's hands takes a team of people working together. And this is not management directed, this is how programmers who have set aside ego to get a product out choose to work. Consider that all the great Disney movie sound tracks and most broadway musicals were written by two people working together.

   Re:I much rather like sole systems (Score:2) by Cuthalion on Wednesday December 29, @12:20PM EST (#226) (User Info) http://fridge.auspice.net/~cuth

   I emphatically do not agree that two pairs are better at design and code construction time I definately have had very different experiences than you, though not in terms of corporate coding (which is what I do during the day that keeps me from coding for fun all of the time). All of the most successful hobby projects I've worked on (and some have been very successful)have been collaborative efforts between me and another coder. We've worked together productively on all parts of projects - from design (often in a coffee shop) to implementation (less often in a coffee shop) to debugging and optimizing (never in a coffee shop). I don't know how often this kind of thing works, though. I certainly find myself talking over design issues with my co-workers (in both "my" modules and "theirs") but that's not as symmetric. It would be foolish to argue that this always works, or that any two coders working together will compliment each other. I'm merely writing to anecdotally point out that it can happen. Disclaimer: I'm not as smart as I think I am.

   Re:I much rather like sole systems (Score:1) by Captain Teflon on Tuesday December 21, @02:23PM EST (#143) (User Info)

   Get praise for the work you do right, and be ashamed for your mistakes. I think this happens a lot quicker and at peer rather than management level using the team approach. I also think you learn more when forced or encouraged to bounce ideas off each other rather than working alone in a box. Finding everything out for yourself when another person could show you how in five minutes is just plain stupid IMHO. I don't think anyone suggested that each day a different pair of programmers take up where the last one left off. That I agree would be lunacy. 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. That puts the onus on the manager for checking the code. Great, as long as you're not the manager. Team review, testing and debugging, allow him to do what he should be doing, making decisions, arranging resources and support, reviewing schedules and running interference with the PHB's. Team debugging may put more onus on you to do the less glamourous testing work, and illuminate your errors and shortcomings for all to see. If you can't handle that, you shouldn't be in business application development. It's a whole lot worse when your customers find the bugs that your peers on the team could have caught. (the strong make up for the weak). In my 23 years of programming, the strong are usually only too happy to expose the weak. If management are any good they'll do something about it (training the inexperienced, firing the lazy and incompetent, counselling or firing the prima donnas). Eagles may soar, but weasels don't get sucked into jet engines.

   Re:I much rather like sole systems (Score:1) by Basje (basje@mypad.com) on Wednesday December 22, @06:37AM EST (#192) (User Info)

   I know this is off topic. Feel free to moderate me down. But not being able to moderate I just have to say this: hear hear! ---------------------------------------------- First post? Impossible if you think before you type!

   end user v. manager feedback (Score:3, Interesting) by Pfhreakaz0id on Tuesday December 21, @09:25AM EST (#8) (User Info)

   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. Why anonymity is good http://www.cato.org/pubs/briefs/bp-054es.ht ml

   Re:end user v. manager feedback (Score:1) by 10am-bedtime on Tuesday December 21, @03:42PM EST (#157) (User Info) http://www.glug.org/people/ttn/

   business programming is real programming but it's really programmed programming. it will be one of the first segments in the software industry to crash. --thi

   watch your scope run away (Score:2, Informative) by zzzeek (classic@ispamo.com) on Tuesday December 21, @06:40PM EST (#166) (User Info)

   my experience with minute-by-minute customer feedback is that the entire notion of a functional specification is lost immediately, as about one out of every five opinions they have on something will in fact be a new feature they just thought of now that they are seeing their product come to life. Having the customer sit with the programmer all the time means there is no project management layer in between, its just the client making demands directly to the programmer who has much more pressing (and non-programmer intangible) issues on his/her mind than all the random little frills that should have been spec'ed out and properly scheduled. All of the customer's thoughts and use case scenarios should be gathered into a proper and complete specification before any programming work is begun - if the programmer needs to ask questions to the customer during development, then the specification was not completed. Continuing down the road of developing a large project without a roadmap will guarantee project failure, major psychological/physical trauma to your programmers, or both.

   Re:watch your scope run away (Score:1) by gtstellf on Wednesday December 22, @10:11AM EST (#193) (User Info)

   I have heard these comments from most of the PMs that I have talked to about XP and I think the issue comes down to one of the illusion of control. If I am in control I can keep the project from failing, the programmers from going insane and the users from being dissatisfied. The problem is this illusion is hard to maintain. IMO XP says let go of that illusion, and embrace the change that is going to be in the process. If I keep with the core values and principles, I find by letting go of the control I thought I could create I am actually in more control of the process. XP ASAP.

   Re:watch your scope run away (Score:1) by Martijn Meijering on Saturday December 25, @01:17PM EST (#216) (User Info)

   Fortunately, what you describe is not the way Extreme Programming works. See http://www.extremeprogramming.org/rules/planninggame.html for how XP does planning.

   Re:watch your scope run away (Score:1) by DonWells on Sunday December 26, @02:33PM EST (#224) (User Info)

   I am not sure why getting new ideas, often better ideas, is a problem. The way XP addresses scope is to make it clear resources are limited. With the given resources the customers get to choose what they want to pay for. If they want a suite of useless frills that is their business. But in reality customers want important base line functionality first. More often than not it is the programmers who want kool bells and whistles first. Customers are free to put as many frills on cards to be implemented in the future as they like. If they find something even more important than something already in the schedule they are free to swap it. It is up to them, but they are not allowed to just add extra functionality as they please. Scope is completely under control at all times.

   Re:business programming & Open Source (Score:2) by Pfhreakaz0id on Tuesday December 21, @08:01PM EST (#172) (User Info)

   I found your comment about Business Programming being "programmed programing" interesting. A fair amount of what I do is repetitive (I would argue that some is not. That some businesses are so specialized in what they do and so convuluted in how they go to market that no AI computer program could ever replace a talented System Analyst and programming team). This dovetails nicely with something I came across on the web the other day. General Office. It's an Open Source Accounting package. Many different modules. Ability to use a large variety of data sources (Access, SQL server, Oracle), although with the source you could use anything without too much problem. Written in VB6, source included. LIcensing options for resellers. I thought "man, we can start with that, customize for the client, and it'd be like doing a whole custom app for them!" I think this is a GREAT idea. Why anonymity is good http://www.cato.org/pubs/briefs/bp-054es.ht ml

   cost? (Score:2, Interesting) by DGregory on Tuesday December 21, @09:29AM EST (#12) (User Info)

   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.

   Re-writing code costs more-do it right 1st time (Score:1) by Da VinMan (VincePlatt@yahoo.com) on Tuesday December 21, @09:45AM EST (#26) (User Info)

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

   Re:cost? (Score:1) by richieb (richieb@netlabs.net) on Tuesday December 21, @10:02AM EST (#38) (User Info) http://www.netlabs.net/~richieb

   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.... ...richie

   Re:cost? (Score:0) by Anonymous Coward on Tuesday December 21, @11:30AM EST (#87)

   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.

   Re:cost? (Score:1) by ranton (ranton@uti.com) on Tuesday December 21, @01:11PM EST (#122) (User Info)

   I am sure that two people working seperatly would get done much faster than two people working together. Just think of the programmer that is simply looking over the actual coder's shoulder. How long will he be paying attention untill he has had enough? How long could a (usually egotistical) programmer stand being told that he missed another semi-colon untill he started ignoring the other bystandard. Two people working seperatly (while sharing finished functions and classes of course) would finish much faster since they would both be using their full abililty at all time.

   Re:cost? (Score:1) by richieb (richieb@netlabs.net) on Tuesday December 21, @01:22PM EST (#130) (User Info) http://www.netlabs.net/~richieb

   I am sure that two people working seperatly would get done much faster than two people working together. Just think of the programmer that is simply looking over the actual coder's shoulder. How long will he be paying attention untill he has had enough? Perhaps they could finish writing the code and getting it to compile sooner. But I would bet that a pair of programmers would have a debugged version much faster than two separate programmers. In pair programming the programmers talks as the code is written. The talking makes a huge difference. Think of is as an instantenous code review. ...richie

   Re:cost? (Score:1) by Martijn Meijering on Saturday December 25, @01:41PM EST (#218) (User Info)

   The point about talking is very important. Having someone looking over you shoulder is not what we mean by pair programming. Pair programming is about synergy, not distrust.

   Re:cost? (Score:2, Insightful) by pieguy on Tuesday December 21, @10:32AM EST (#55) (User Info)

   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. ------------------------------------ Your perception that I am alien is partly correct. My Father was Human.

   Re:cost? (Score:0) by Anonymous Coward on Tuesday December 21, @11:06AM EST (#76)

   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:cost? (Score:0) by Anonymous Coward on Tuesday December 21, @10:52AM EST (#67)

   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.

   Re:cost? (Score:0) by Anonymous Coward on Tuesday December 21, @01:53PM EST (#138)

   Perhaps a better analogy is two players shooting vs. one player shooting and the other watching him.her and advising how to shoot better. - Skeptik

   Re:cost? (Score:1) by segmond (segmond[at]hotmail[dot]com) on Tuesday December 21, @01:53PM EST (#139) (User Info)

   Yes, "if they can get that 2nd pair of eyes to go program something else". Notice the word, IF. Sadly, most programmers are not disciplened enough to work on their own in large projects. If you have a project that is going to be 20,000 lines of code. It will be much faster having a two people work together as a pair, then having each go his way and code seperate 10,000. This problem is like the classic problem, of 1 towel takes 10 minutes to try, how long does 2 towel take? some will answer 5, some will answer 20, the answer remains 10. My reflection, dirty monitor, there is no connection, to the net.

   Re:cost? (Score:2, Insightful) by waveman on Tuesday December 21, @02:35PM EST (#146) (User Info)

   I have been using XP for a while, and I found that the whole is more than the sum of the parts. True, no element is entirely new, but when you put them together everything works. Pair programming is an example. The previous poster claimed without any evidence that programming alone is more productive. I don't think it is, when you take into account that with pairs you get fewer errors, cleaner code, and better distribution of knowledge across the team. And less need for doco. The existence of unit tests for example enables you to add features and clean up code later on. One reason for 'big design up front' is that the cost of changes later on is so high. But with the tests, you don't have to fear making changes. You can then defer adding features until you need them - which may be never. Thus unit testing enables 'just in time' coding. Look at XP as a whole before judging it.

   Re:cost? (Score:1) by DGregory on Tuesday December 21, @04:45PM EST (#161) (User Info)

   I still think that instead of 1+1=2 you're getting 1+1=1.5 ... more productive than just one person but still not as productive as 2 people coding separately. Yes it's faster, cleaner, better than just one person sitting there and coding their stuff by themselves, but by how much? Certainly not double time. And it's the managers and other kinds of people who say well he's just watching, when he could be programming something else! I wonder if there are any studies done on the subject, rather than just theories and people saying "yeah! I get it done faster/better!"

   Re:cost? (Score:1) by gstamp (glen_stampoultzis at ansett.com.au) on Tuesday December 21, @06:51PM EST (#167) (User Info)

   I have seen some studies. There's a link somewhere on c2.com but I can't think of the page at the moment.

   Re:cost? (Score:1) by Martijn Meijering on Saturday December 25, @01:42PM EST (#219) (User Info)

   See http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF

   Re:cost? (Score:2, Interesting) by BinxBolling on Wednesday December 22, @12:27AM EST (#183) (User Info)

   I still think that instead of 1+1=2 you're getting 1+1=1.5 ... more productive than just one person but still not as productive as 2 people coding separately. Yes it's faster, cleaner, better than just one person sitting there and coding their stuff by themselves, but by how much? Certainly not double time. On the contrary, I could easily imagine pair programming leading to a 1+1=2.5 increase in productivity. One of the basic points Fred Brooks makes in The Mythical Man-Month is that there is not some intrinsic amount of effort that a software development task 'ought' take. (Indeed, this is the source of the book's title.) Not all man-hours are created equal. Of course this is obvious, since not all programmers are of equal skill. But even for a single programmer, some hours are more productive than others. He may hit upon an abstraction that drastically simplifies coding for the bulk of what his program must do, and as a result accomplish a great deal in a very short period. Or he may hit a wall, get frustrated, and go off to stew and play solitaire for an hour. Though I've never tried it, I suspect that pair programming could increase the productivity of the average man-hour sufficiently to more than make up for the halving of programmer resources: With two minds working on a problem, the chances of finding a useful abstraction increases quite a bit. And when a wall is hit, the bystander's presence will motivate the coder to either keep working and find a solution, or at least go off and work on some other part of the code that isn't affected by that wall. Of course, this all depends on both the qualities of the two individuals, their abilities to work together, and the nature of the task at hand. If the task at hand is relatively simple (i.e read a bunch of records in from a database table, generate a neatly formatted report), that second pair of eyes won't improve productivity much. But for more complex programs, it probably will.

   Re:cost? (here, here) (Score:0) by Anonymous Coward on Wednesday December 22, @01:20PM EST (#196)

   This thread just proves that most "slashdotters" do not live in the real world. Try working for a living for and you'll quickly see that most thing you do code-wise make little sense, and most of the time its not your fault.

   Actually you reduce the cost. (Score:1) by DonWells on Thursday December 23, @09:53AM EST (#209) (User Info)

   Studies have already shown that pair programming produces as much code as two people working separately. But the quality is much higher and that saves you time in the long run.

   Ahead of my time (Score:2, Insightful) by Relic of the Future (relic@thekeySPAMboard.com) on Tuesday December 21, @09:29AM EST (#13) (User Info)

   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 "Stop telling God what to do." -Niels Bohr

   Debugging Party (Score:2, Interesting) by Midnight Ryder (midryder@midnightryder.com) on Tuesday December 21, @11:20AM EST (#84) (User Info) http://www.midnightryder.com

   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 Opening Jan 3, 2000 - www.midnightryder.com

   Re:Debugging Party (Score:0) by Anonymous Coward on Tuesday December 21, @03:13PM EST (#152)

   Peer-review of the source code, what a novel concept. I wonder why this haven't become a fad yet?

   Re: Peer-review ... novel concept? (Score:0) by Anonymous Coward on Wednesday December 22, @01:17PM EST (#195)

   I wonder why this haven't become a fad yet? Because no one does it! Let's get real. Most Code-Review is a waste of time. Hours and hours of person time is wasted in what seems like should work, but never has. What usually happens is a bunch of people sit around, looking at code listings, making superfluous comments about style and imagined execution. They are as a whole, unable provide ANY meaningful value in terms of evaluating context or correctness. IMO, the only result is mass MEGO.

   Re: Peer-review ... novel concept? (Score:1) by SamesShuster (sames at interaccess dot com) on Wednesday December 22, @01:43PM EST (#199) (User Info)

   Sorry about the double post, And So It Goes Sames

   Re: Peer-review ... novel concept? (Score:1) by SamesShuster (sames at interaccess dot com) on Wednesday December 22, @01:39PM EST (#198) (User Info)

   I wonder why this haven't become a fad yet? Because no one does it! Let's get real. Most Code-Review is a waste of time. Hours and hours of person time is wasted in what seems like should work, but never has. What usually happens is a bunch of people sit around in endless dreadful meetings, looking at lifeless code listings, making superfluous comments about style and imagined execution. They are as a whole, unable provide ANY meaningful value in terms of evaluating context or correctness. IMO, the only result is mass MEGO. The question is, "Is Code Review Good?" I believe it is in theory, if it worked, but in practice it doesn't. So I believe the answer is, do it all the time, not as an exercise in seeing how many people you can get to come up with different opinions on where to put a curly brace! How do you do it to make it work? How do you do it to make it work all the time? The only answer I have found that actually works is Pair Programming. Don't trust your programmers to know what they're doing? To work cooperatively with each other instead of building cowboy kingdoms of knowledge? To share their knowledge and take the time to do the most difficult of all programming tasks: communicate? The answer my friends is simple: If you don't trust them, FIRE THEM! And So It Goes Sames

   I did this too; it worked great! (Score:2, Insightful) by Anonymous Coward on Tuesday December 21, @01:46PM EST (#136)

   I tried pair programming here at work [WebObjects/ObjectiveC], and it worked wonderfully! We came out ahead of when we thought we could get through, had very few errors along the way, and had a LOT of fun. I remember that when my partner left, everything suddenly seemed to slow down. Two people working on a problem at once has a synergetic effect. It forces a laser-like attention without distraction, and shows views of things from more than one angle. At least, that's my explanation for what happened. An absolutely wonderful experience. Read the articles here: you'll notice a lot of SPECULATIVE "I don't think it will work"s, and you'll notice a lot of "We DID it, and it works great." Lion Kimbro =^_^= . o O ( Someday I'll get yet another Slashdot account...)

   Part time job (Score:1) by ranton (ranton@uti.com) on Tuesday December 21, @02:25PM EST (#144) (User Info)

   Too bad I wasnt in your class or you could have done what most of my classmates did. They looked over my shoulder watching me while they handed me $30 to rewrite my programs enough so that they could hand it in too. I rewrote my C++ final program five times! That was the easiest $150 dollars I ever made, and I did it in one class period (about 1 hour). $150 an hour isnt bad for a college kid. Too bad that only happened once every other week when programs were due, cause it was more lucrative than writing people's term papers for them. Too bad that they will grow up to be bad programmers later, but I guess that will give more jobs to me.

   Re:Part time job (Score:0) by Anonymous Coward on Tuesday December 21, @03:16PM EST (#154)

   You have been reported to your school officials you cheating bastard.

   Re:Cheating (Score:1) by SamesShuster (sames at interaccess dot com) on Wednesday December 22, @02:07PM EST (#200) (User Info)

   Isn't it interesting. Isn't it interesting that all through our school years, we are told over and over that working WITH another is cheating. And what happens the first time we get out in the business world? We're told "We want team players!" But we have no experience in doing that. So, as programmers, we talk the talk of "Team" and Tony What's-His-Name and sharing and empowerment, but the moment we start to work, we revert to the Cowboy ethic, which is, after all, the only thing we know. The very idea of Pair Programming and Communal Code Ownership is so foreign to us as to not even make sense to us. It doesn't seem rational much less possible. So we just say "It Doesn't Work", "It's Less Productive", "If Only We Did Right What We're Doing Now, We Wouldn't Be Talking About This Idiotic Fantasy" And there in a nutshell is the problem. XP is an attempt to define a process where "YOU" are truly empowered, not just some lip service where in the end you just go back to your closed door office and pound the keyboard, Twinkie and Latte in hand. "But Sharing Gets Me Nowhere!" you say in the quiet of your mind. "Power and career advancement does not come from sharing." True enough. In the "Real World" it comes from having knowledge and demonstrating ability that others do not have. This XP stuff all seems like some Utopian world where everyone knows the project that they're working on, can help anyone on their team with any part of the project, can be unafraid to attack a new or old part of the project that they've never seen before, to try new things all the time without worry that it will break something. Yup. It's purely the things dreams are made of. Except... Except... It works. When all is said and done, and you do all of the practices, and you put your pride on the line that you will do the best for the PROJECT and the PROCESS as a whole instead of your small corner of the world, it works. But that would be cheating! And So It Goes Sames

   Planning is good! (Score:2, Insightful) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @09:29AM EST (#15) (User Info) http://www.worldwindtech.com

   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.

   Re:Planning is good! (Score:3, Informative) by devphil on Tuesday December 21, @09:58AM EST (#36) (User Info)

   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! (Score:2, Insightful) by johnburton (johnb.sd@jbmail.com) on Tuesday December 21, @09:59AM EST (#37) (User Info) http://www.jbmail.com/

   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:Planning is good! (Score:1) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @10:04AM EST (#40) (User Info) http://www.worldwindtech.com

   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.

   Re:Planning is good! (Score:1) by johnburton (johnb.sd@jbmail.com) on Tuesday December 21, @10:06AM EST (#44) (User Info) http://www.jbmail.com/

   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! (Score:1) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @10:12AM EST (#48) (User Info) http://www.worldwindtech.com

   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! (Score:1) by johnburton (johnb.sd@jbmail.com) on Tuesday December 21, @10:22AM EST (#51) (User Info) http://www.jbmail.com/

   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:Planning is good! (Score:1) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @10:28AM EST (#53) (User Info) http://www.worldwindtech.com

   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.

   Re:Planning is good! (Score:1) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @10:07AM EST (#45) (User Info) http://www.worldwindtech.com

   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:Planning is good! (Score:1) by johnburton (johnb.sd@jbmail.com) on Tuesday December 21, @01:40PM EST (#134) (User Info) http://www.jbmail.com/

   It's much better to plan increments of functionality rather than "modules" as you can implement, test and ship code at any point. For some reason, many "management" people still seem to want to define and develop "modules" instead. So you have *no* working functionallity until the end of the project when in theory you have 100%. In fact this is the point you test and discover the faults but have no time left to fix them.

   Re:Planning is good! (Score:2, Informative) by udin (udin at pce dot net) on Tuesday December 21, @10:12AM EST (#49) (User Info)

   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. udin

   Re:Planning is good! (Score:1) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @10:18AM EST (#50) (User Info) http://www.worldwindtech.com

   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! (Score:0) by Anonymous Coward on Tuesday December 21, @11:45AM EST (#94)

   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:Planning is good! (Score:1) by gstamp (glen_stampoultzis at ansett.com.au) on Tuesday December 21, @07:07PM EST (#169) (User Info)

   The problems with analysis and design documents are that you can't run or test them. Therefore how do you know they are correct?

   Re:Planning is good! (Score:1) by Martijn Meijering on Saturday December 25, @02:16PM EST (#222) (User Info)

   Planning is a very important part of XP. XP does planning by playing the "Planning Game". See http://www.extremeprogramming.org for an excellent overview. Analysis and design is done through "merciless refactoring". It turns out to be very hard to convince some people that this is not hacking. XP has very high standards for code quality. See my home page for examples of XP code (http://www.wi.leidenuniv.nl/~mmeijeri). I hope you'll agree this is not horrible code. At the same time many people who do believe that this will work because that's "what they've been doing all along" are probably not doing it mercilessly enough. Showing people how to do it turns out to be easy though. A while ago on otug and comp.object I suggested doing a XP demo via MS NetMeeting and I got a lot of positive reactions. Setting a time and date turned out to be hard. If any of you want to give it a try, try to reach me with NM at 194.151.45.193.

   Extreme Programming not so extreme (Score:2, Interesting) by Anonymous Coward on Tuesday December 21, @09:34AM EST (#16)

   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.

   Re:Extreme Programming not so extreme (Score:0) by Anonymous Coward on Tuesday December 21, @10:50AM EST (#65)

   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:Extreme Programming not so extreme (Score:1) by DonWells on Thursday December 23, @09:48AM EST (#208) (User Info)

   I am not sure what you mean by "hacking mentality". To me it means lacking a disciplined approach to software development. But Extreme Programming is about discipline and quality. I am not sure what quality engineering practices are missing. He has code reviews, unit tests, functional tests, design reviews, and intense analysis.

   Sounds Promising (Score:3, Informative) by Anonymous Coward on Tuesday December 21, @09:34AM EST (#17)

   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.

   Re:Sounds Promising (Score:1) by psaltes (vox@tmbg.org) on Tuesday December 21, @02:02PM EST (#141) (User Info)

   That was a great article. Someone should moderate you up.

   Pair programming works!!! (Score:2, Interesting) by Da VinMan (VincePlatt@yahoo.com) on Tuesday December 21, @09:35AM EST (#18) (User Info)

   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?

   Re:Pair programming works!!! (Score:2, Interesting) by pieguy on Tuesday December 21, @09:55AM EST (#34) (User Info)

   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. ------------------------------------ Your perception that I am alien is partly correct. My Father was Human.

   Re:Pair programming works!!! (Score:1) by oddjob on Tuesday December 21, @11:04AM EST (#74) (User Info)

   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:Pair programming works!!! (Score:1) by pieguy on Tuesday December 21, @11:14AM EST (#81) (User Info)

   AMEN!!!!! ------------------------------------ Your perception that I am alien is partly correct. My Father was Human.

   What is the "engineering phase"? :) (Score:1) by GoofyBoy on Tuesday December 21, @09:37AM EST (#19) (User Info)

   >who need to do programming but don't have time to do the engineering phase Whoa. People have time to do the enginerring phase?!?!?

   Enginerring? (Score:0) by Anonymous Coward on Tuesday December 21, @10:05AM EST (#42)

   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.

   Re:What is the "engineering phase"? :) (Score:2) by JordanH (jordan@greenapple.com) on Tuesday December 21, @10:40AM EST (#60) (User Info)

   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 Try Customizing your Slashdot Display to "Light"(see preferences). It's faster and the simple display helps you to focus on content.

   Re:What is the "engineering phase"? :) (Score:2) by Eric Green (e_l_green@hotmail.com) on Tuesday December 21, @12:58PM EST (#118) (User Info) http://members.tripod.com/~e_l_green

   I think the biggest problem is that "code monkeys" don't know how to write, don't want to write, don't like to write. I take a day out of the development cycle from time to time to modify and continue my write up of what I've done so far -- not the detailed low-level implementation (that's done in the code), but the Big Ideas -- protocol descriptions, overall program structure, what requirements led me to implement certain things in certain ways. Then I clarify what I'm going to be working on for the next week or two in that same way, and circulate that requirements doc around the office to make sure that I'm not missing something obvious. Yes, I took a day to specify the requirements for one program that I'm working on. So what. That saves weeks in overall development time, since I won't need to throw away that work in the future due to an implementation that doesn't meet future requirements. -E -- There is no conspiracy. [Not speaking for my cats!]

   It's not bad at all (Score:2, Informative) by greendot (greendot@y.a.h.o.o . c.o.m) on Tuesday December 21, @09:38AM EST (#20) (User Info)

   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.

   Re:It's not bad at all (Score:1) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @09:46AM EST (#27) (User Info) http://www.worldwindtech.com

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

   Re:It's not bad at all (Score:1) by aeonek on Tuesday December 21, @10:08AM EST (#46) (User Info)

   I think he's hunting for (Score:3, interesting). "True, linux is monolithic, and I agree that microkernels are nicer. " - Linus Torvalds

   Re:It's not bad at all (Score:1) by A Big Gnu Thrush on Tuesday December 21, @11:03AM EST (#73) (User Info)

   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:It's not bad at all (Score:1) by greendot (greendot@y.a.h.o.o . c.o.m) on Wednesday December 22, @11:39AM EST (#194) (User Info)

   That's what I get for reading and writing too early in the morning. We've only started "officially" doing it recently. People have been hired on that used it before and various internal projects were used to test with. But, until I work with it on different types of projects, I'm going to hold back any judgement. Right now, it's fun and interesting. Next year, who knows. Maybe my lackluster view is due to the empty food hole in my stomach right now. ;) -j

   Library Coding Tip (Score:2, Insightful) by Eamonn O'Synan (duncan.cragg.at.chase.com.not@spam.me.com) on Tuesday December 21, @09:42AM EST (#22) (User Info)

   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. -------------------------------------- Dere's a storm a-comin'...

   Re:Library Coding Tip (Score:1) by BeanThere (djoRemovethiSffe@geocities.RemoooovethiS.com) on Tuesday December 21, @11:38AM EST (#91) (User Info) http://www.geocities.com/SoHo/Lofts/2018/

   "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.

   Re:Library Coding Tip (Score:1) by questor (questor@mediaone.net) on Tuesday December 21, @12:44PM EST (#114) (User Info)

   > Either he changes your functions or he adds new similar-but-different functions. In XP, he can "change your functions"; the unit tests make sure that nothing breaks. (And they're not "your" functions anyway, since there's no code ownership.) And the potential problem of similar-but-different functions are covered by the practices of refactoring and of saying/doing things no more than once. Read the book and the web sites before jumping to conclusions.

   Re:Library Coding Tip (Score:1) by BeanThere (djoRemovethiSffe@geocities.RemoooovethiS.com) on Tuesday December 21, @01:12PM EST (#123) (User Info) http://www.geocities.com/SoHo/Lofts/2018/

   "the unit tests make sure that nothing breaks" To have set up a "unit test" you must already have defined some sort of spec to test against, which isn't what I was talking about. "the potential problem of similar-but-different functions are covered by the practices of refactoring" Refactoring is a fix-it-after-its-happened strategy. In our company that has turned out to be far more costly than just doing proper planning to begin with. I'm just skeptical, thats all - at a glance the proposals sound exactly like advocating practices that have gotten us into sticky messes before, so I have the right to be skeptical.

   The Unit Test *IS* the SPEC and ReFactoring Wins (Score:1) by john@iastate.edu on Tuesday December 21, @02:55PM EST (#147) (User Info)

   "To have set up a "unit test" you must already have defined some sort of spec to test against, which isn't what I was talking about" Actually, in a way the unit test IS the spec. "Refactoring is a fix-it-after-its-happened strategy. In our company that has turned out to be far more costly than just doing proper planning to begin with." Yes, it is a fix-after strategy, but it is one I have found really works (even long before I had ever heard of XP). Very often I find myself chopping a function in half or sucking the middle out. It takes me *very* little time to turn: int foo ( ) {   int a1;   int a2;   do {something} while (sometest);   do {more} while (another); } into: int foo ( ) {   int a1;   do {something} while (sometest);   bar(); } int bar ( ) {   int a2;   do {more} while (another); } If I discover I need to use the 'bar' functionality someplace else. Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra

   Re:Library Coding Tip (Score:1) by Martijn Meijering on Sunday December 26, @11:26AM EST (#223) (User Info)

   "Refactoring is a fix-it-after-its-happened strategy. In our company that has turned out to be far more costly than just doing proper planning to begin with." That's the case if you wait to long before you refactor. In XP you divides engineering tasks up into baby steps. First you write a test. This should take no more than a couple of minutes, usually much less. Then you write code for a couple of minutes. The tests tell you when you're done. Then you clean up your code using XP very high standards for code quality. You repeat this for all baby steps.

   Re:Library Coding Tip (Score:1) by SamesShuster (sames at interaccess dot com) on Wednesday December 22, @02:36PM EST (#201) (User Info)

   You're right of course.. IF. If you do not Refactor Mercilessly. If you do not have Unit Tests covering all code. If you do not pursue the Simplest Thing That Can Possibly Work. If you do not work in pairs. If you do not Embrace Change. --AND-- If you think that todays Design Document will cover all of tomorrows problems. If you think the Design & Analysis Documents will exactly match the finished product. If you think the feature set is frozen at the end of Design. If you think you can accurately estimate the time for implementation before it starts. --OR-- You can do it with XP, and realize it MUST work without one of those boring library design meetings. Because it hasn't worked yet, your way. And So It Goes Sames

   Re:Library Coding Tip (Score:1) by BeanThere (djoRemovethiSffe@geocities.RemoooovethiS.com) on Friday December 24, @05:50AM EST (#210) (User Info) http://www.geocities.com/SoHo/Lofts/2018/

   "If you do not Refactor Mercilessly" We've already wasted a lot of money refactoring code that should have been done cleaner from the start. "If you do not pursue the Simplest Thing That Can Possibly Work" We write Virtual Reality simulators for PC's. Almost nothing of what we do is simple. The core technologies are complex. Writing them 'as simple as possible' has in the past time and again proven to result in code that is not re-usable without putting a whole lot more work in to clean the code up. "If you do not Embrace Change" "Embracing change" does not have to mean "rewrite from the ground up when your needs change. Trust me, in PC 3D graphics, you have to embrace change, because hardware and software are evolving quickly. If you design well, you can take advantage of new hardware etc by just making changes to relevant modules. If you design badly, you're screwed. No matter what you do though, in 3D graphics, every few years you should be prepared to rewrite large chunks of your API, but that does not mean ignoring planning and re-use. "If you think the feature set is frozen at the end of Design" This is ridiculous. You come across as someone who knows very little about more "traditional" software design techniques. I acknowledge that I need to read up more about XP, but I suggest you read up more about conventional planning and design, which most definitely does NOT imply feature sets "frozen at the end of design" unless you don't know what you're doing. "If you think you can accurately estimate the time for implementation before it starts" Are you telling me that in XP the time estimate problems are magically solved? That the managers don't want to have time estimates anymore? That with XP you can magically more accurately estimate times?

   Re:Library Coding Tip (Score:1) by SamesShuster (sames at interaccess dot com) on Friday December 24, @01:57PM EST (#212) (User Info)

   "Refactor Mercilessly" -- "Wasted Time" You might not like this answer then. You didn't Refactor Mercilessly. Refactoring as a discreet development task is almost always a waste of time. Refactoring as a part of the process of adding or modifying a feature, as an intrinsic way of developing never is. The Refactoring you talk about is simply the rearranging the deck chairs on the Titanic. The Refactoring I talk about is the constant incremental improvement of code to assure that it always matches the current Best Vision of what the product/function should be. "Simplest Thing That Can Possibly Work" -- "Almost nothing of what we do is simple" Well, I work on enterprise applications, and I assure you, they are not simple either. Don't confuse E-Z with Simple. Simple is almost never E-Z. And it isn't about "as simple as possible" either! The simplest thing that can possibly work is often very hard, complex work. But it NEVER is more than is needed. It never attempts to guess what I will need tomorrow, only what I need today. Then, coupled with Refactoring as a intrinsic part of development, I am unafraid to add what is needed tomorrow, when I know what it is. Each identifiable increment is then the most simplest thing that can possibly work. The difficulty or ease in doing it has nothing to do with this idea. "Embrace Change" -- "does not mean ignoring planning and re-use." Mostly, I agree with your statements. I though have yet to see anyone accurately predict what the future will bring, and therefore, it is better to take a position of Embracing Change instead of pretending you can predict the future. Planning for now is one thing. Pretending one can accurately plan for the future is one of the "Big Lies" of our industry. One of the other "Big Lies" of our industry is being able to plan for Re-use. Constant incremental refactoring is Re-use in practice, there really is nothing else except the puffed up statements of supposed computer industry experts (an oxymoron at that!). "Frozen at the end of Design" -- "You're Ignorant" Well, whether I'm ignorant or not is not in dispute here. What is in dispute is if "Traditional" software design techniques imply feature sets are frozen at the end of design. I suggest you go back and read the traditional Waterfall process texts, and find where they imply where the features change within an iteration. I don't consider Spiral methods to be Traditional, but that could be a matter of opinion where we might disagree. Even so, in practice, none of these takes into account how to deliver on time, and still react immediately to new feature requests. XP's Planning Game, Stories, Engineering Tasks and Full Time Business Person does address this. "Accurately Estimate Time" -- "(Three Distinct Questions)" Question 1: XP Time increments are exact. At the end of every increment, there is a tangible deliverable, and there is no question that it is exactly what the Business User agrees with. Question 2: Of course, all managers want to have time estimates. How its done changes, not the need. Question 3: Yes. Except of course, it's not magic, its hard work. And So It Goes Sames

   Extreme programming (Score:1, Funny) by VAXGeek on Tuesday December 21, @09:44AM EST (#23) (User Info)

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

   Does this book seem to be pushing a BAD idea? (Score:1) by GoofyBoy on Tuesday December 21, @09:44AM EST (#25) (User Info)

   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:Does this book seem to be pushing a BAD idea? (Score:1) by Anonynous Coward on Tuesday December 21, @09:54AM EST (#33) (User Info)

   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:Does this book seem to be pushing a BAD idea? (Score:0) by Anonymous Coward on Tuesday December 21, @10:26AM EST (#52)

   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:Does this book seem to be pushing a BAD idea? (Score:1) by RobertEdwards on Tuesday December 21, @11:23AM EST (#86) (User Info) http://www.nashville.com/~robert.edwards/index.htm

   "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?

   No More Code Monkeys! (Score:1) by john@iastate.edu on Tuesday December 21, @03:26PM EST (#155) (User Info)

   "the code maintance people will have a hell of a time." That's part of the problem -- even having "code maintenance people"! Because, typically, that means the 'hotshots' are all doing feature-creep and the 'code monkeys' are doing maintenance -- is it any wonder we get bloated BSoD crapware as a result? Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra

   Re:Does this book seem to be pushing a BAD idea? (Score:1) by alan_knight on Tuesday December 21, @08:26PM EST (#174) (User Info) http://www.objectpeople.com

   There are no maintenance people, everything is maintenance after the first iteration.

   Re:Does this book seem to be pushing a BAD idea? (Score:0) by Anonymous Coward on Wednesday December 22, @04:48AM EST (#191)

   The book also seems to be advocating bad coding. Its what I went to university to learn how not to do What University did you go to? In ]]]]]]]]]

   ... (Score:1) by Anonynous Coward on Tuesday December 21, @09:51AM EST (#30) (User Info)

   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:... (Score:1) by staplin on Tuesday December 21, @12:13PM EST (#102) (User Info)

   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:... (Score:1) by GBSW on Tuesday December 21, @01:19PM EST (#128) (User Info)

   In fact, you are quite wrong. XP was developed for the smalltalk system, which is more OO than C++ or any other language out there. Refactoring is not negating OO, it is simply saying "don't be so freakin' chicken to change your code to make it MORE oo and thus more re-usable".

   Spiral rehash? (Score:3, Insightful) by Mr Neutron (neutron@doppke.com) on Tuesday December 21, @09:54AM EST (#32) (User Info)

   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." Neutron I get my kicks above the .sigline, Sunshine.

   Re:Spiral rehash? (Score:0) by Anonymous Coward on Tuesday December 21, @03:08PM EST (#149)

   XP is similar to Spiral. The difference is in the scale: with Waterfall, you design; then you code; then you test; and that's it. Each phase takes weeks or months. With Spiral, you have short iterations in which you do design, code, and test for a small number of features or a portion of the program. Each phase takes a couple of days. With XP, you do design, code and test in iterations, as before, but each phase is only a few minutes long. It's a way to maximize the amount of feedback you can derive from the coding process. Try it -- you may like it!

   Extreme Programming web site (Score:4, Informative) by dsplat on Tuesday December 21, @10:05AM EST (#41) (User Info)

   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.

   Re:Extreme Programming web site (Score:1, Interesting) by Anonymous Coward on Tuesday December 21, @10:41AM EST (#61)

   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: http://www.xprogramming.com/

   Re:Extreme Programming web site (Score:0, Troll) by Anonymous Coward on Tuesday December 21, @10:54AM EST (#69)

   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.

   Re:Extreme Programming web site (Score:1) by questor (questor@mediaone.net) on Tuesday December 21, @11:46AM EST (#95) (User Info)

   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...

   Don't forget www.ExtremeProgramming.org (Score:2) by cpeterso on Tuesday December 21, @01:19PM EST (#127) (User Info)

   For a gentle introduction, check out ExtremeProgramming.org. They also have a nice on-going column about developing an "extreme"-style coffee maker. chris

   Too many eyes (Score:3, Funny) by dmorin on Tuesday December 21, @10:06AM EST (#43) (User Info)

   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."

   So did it fix the problem? (Score:0) by Anonymous Coward on Tuesday December 21, @07:14PM EST (#170)

   No, really.

   Communication and Specification (Score:2) by adimarco (adimarco@spam.me.and.die.gwi.net) on Tuesday December 21, @10:11AM EST (#47) (User Info) http://www.lies.org

   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... Anthony

   I'm with you! (Score:2) by DanaL (DanaLarose@netscape.net) on Tuesday December 21, @10:53AM EST (#68) (User Info)

   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. Dana Spellchecking is for imagination impaired drones who wouldn't know poetry if a Dr. Seuss book fell off a shelf and fractured their skull.

   Re:I'm with you! (Score:2) by adimarco (adimarco@spam.me.and.die.gwi.net) on Tuesday December 21, @11:05AM EST (#75) (User Info) http://www.lies.org

   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... Anthony

   Re:I'm with you! (Score:1) by gstamp (glen_stampoultzis at ansett.com.au) on Tuesday December 21, @07:55PM EST (#171) (User Info)

   This is why need constant direct contact with the customer. The customer should always be made aware of the impact of their changes to the schedule. With XP, this is done by writing up a new card with a description of the change and an estimate of the time required. This is placed into one of the future iterations (How soon depends on importance to the customer and the risk).

   Re:Detailed Specification (Score:1) by SamesShuster (sames at interaccess dot com) on Wednesday December 22, @03:13PM EST (#202) (User Info)

   Yeah, I'd like to see one too. Haven't yet in 20 years in this business. I have time and again asked my Colleagues over the years if any one of them have seen one, but they haven't. So I no longer believe they exist, any more than the Tooth Fairy, Hanukkah Harry, Compassionate Lawyers or Honorable Politicians. That's why I support XP. It finally puts to rest the notion that what hasn't yet worked, should work, and will work, if we only somehow believe it harder... Maybe by clapping our hands together and chanting "I Believe In Detailed Specifications... I Believe In Detailed Specifications..." until Tinker Bell comes back to life. Detailed Specifications are like UFOs. Some people want to believe they exist, and that someone out there has actually seen them. However while the evidence doesn't stand up to the light of day, it doesn't seem to diminish the large amount that is written about them, nor the hope that someday we'll prove they actually exist, despite the government cover-up. It's too bad you don't consider work 'coding for fun.' It speaks volumes about the failure of the processes and procedures that pervade the industry. For me, its always fun. So much so, that I don't feel the want to hack at home much anymore. As a matter of fact, I tend to dislike it because I don't have anyone to work with. But then, I'm a consultant, and when I find a place that isn't fun, I just move on. And So It Goes Sames

   Re:Communication and Specification (Score:2, Informative) by richieb (richieb@netlabs.net) on Tuesday December 21, @11:14AM EST (#83) (User Info) http://www.netlabs.net/~richieb

   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. ...richie

   Re:Communication and Specification (Score:1) by panda on Tuesday December 21, @11:49AM EST (#96) (User Info) http://jason.stephenson.net/

   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:Communication and Specification (Score:1) by mayoff (mayoffslashdot@dqd.com) on Tuesday December 21, @12:21PM EST (#105) (User Info)

   Too bad a signed customer specification (or requirements document) doesn't work. I've seen this many times at several companies. The problem is that the initial reqs/specs are almost always incomplete, erroneous, or infeasible. If you insist on delivering that anyway, you get a customer who doesn't want to pay. Would you rather spend your time and money in court or in the lab? Another possibility is that the customer pays, but doesn't like you. You get no more business from that customer, no reference for your corporate resume, and (depending on how much networking goes on in the customer's industry and/or locale) a bad reputation.

   Re:Communication and Specification (Score:1) by jlowery on Tuesday December 21, @06:10PM EST (#163) (User Info) http://www.seanet.com/~jlowery

   I would agree. I've never met a requirements document yet that wasn't out of date, wordsmithed to death, and still ambiguous as hell. The ONLY thing that is unambiguous is code. Coding is what drives the ambiguity out. Implementation also makes apparent what should have been in the requirements in the first place. Insisting on a 'complete' requirements spec that's tossed over the fence to programmers gets you right back to the good ol' waterfall days, and that methodology has been amply proven in practice not to work. Your only hope is to interact constantly with your customers, and the developers have to be involved. If you have your customer specify requirements without developer involvement, you'll wind up with a crappy system that emulates all the flaws of the the one it was intended to replace. If you beat your customers over the head with their original requirements document, you're not going to have happy customers, either.

   Re:Communication and Specification (Score:1) by Martijn Meijering on Saturday December 25, @01:54PM EST (#220) (User Info)

   "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? " In XP functionality is determined by stakeholders in (verbal!) discussion with the whole development team. This way everybody has a good understanding of what needs to be done. For scheduling and estimation the functionality is recorded as user stories on cards. During implementation of a user story, the developers involved go talk with the stakeholders for more detailed information. No later than halfway through an iteration the stakeholders (supported by developers) come up with detailed tests. They serve both as detailed specification and regression tests. For a very tiny but readable example, see the payroll exercise on my home page (http://www.wi.leidenuniv.nl/~mmeijeri). For a larger example, see the compiler project on the same page.

   Re:Communication and Specification (Score:1) by Martijn Meijering on Saturday December 25, @02:03PM EST (#221) (User Info)

   "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. " In a way this is what XP does. However, every (1 to 4 week) iteration results in a release. So customers get what they pay for very regularly. Then there is no need to insists on good, complete specifications, which is a good thing because there is no such thing as a good, complete specification up front. The great thing about this is that it takes away the mistrust. You don't have to worry about the customer changing his mind at your expense and the customer doesn't have to worry about sinking money into a bottomless pit. Customers are part of the team. The customers continually try their best to come up with the best business value they can think of and the programmers do their best to deliver as much of that as they can. See http://www.xprogramming.com/products.htm for more about the customer-developer interaction.

   Re:Communication and Specification (Score:2) by DanaL (DanaLarose@netscape.net) on Tuesday December 21, @12:43PM EST (#113) (User Info)

   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. But a requirements doc shouldn't really be about implementation details. It's a describe of what the software will do and should be high-level enough to present to a non-programmer. It's true that the client may not know what he/she wants. That's what makes the the requirements so important (at least in my mind). If a project is presented which doesn't do what the client wants and modifications will take a couple of thousand dollars, someone has to absorb that cost. When 'requirements' are decided in phone conversations, 9 out of 10 times, it's our company that absorbs the cost. With a requirements doc that the client has agreed to, we can at least make a case that what he is asking for is new features beyond what we were originally contracted to do. Better still, if the client reviews the documentation and it doesn't match what he wants, he can tell us *before* we get to far into development. Rapid prototyping is very useful (especially for web-based stuff), but I think sometimes it gives the client the illusion that all changes a simple. He often can't understand why adding a couple of new form fields might break the database structure and take several hours. And that makes him think we're trying to gouge him. Req docs aren't perfect, but they are far and away better than nothing at all. Dana Spellchecking is for imagination impaired drones who wouldn't know poetry if a Dr. Seuss book fell off a shelf and fractured their skull.

   Re:Communication and Specification (Score:1) by questor (questor@mediaone.net) on Tuesday December 21, @12:56PM EST (#117) (User Info)

   What if you told the customer that this little change would take X time/cost to implement, while this new feature woult take Y, and let him choose which is worthwhile and which should be done first? Funny, that's what the XP people call the Planning Game...

   Also look at "The Pragmatic Programmer" book (Score:2, Informative) by Woodrow (chriswoodruff.spam@earthlink.net) on Tuesday December 21, @10:31AM EST (#54) (User Info) http://www.worldwindtech.com

   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:Also look at "The Pragmatic Programmer" book (Score:1) by fredb001 on Tuesday December 21, @11:07AM EST (#77) (User Info)

   Check out http://www.pragmaticprogrammer.com/.

   Where Extreme Programming Fails! (Score:3, Insightful) by stephend (slashdot@nospam.zx81.org.uk) on Tuesday December 21, @10:33AM EST (#56) (User Info) http://www.zx81.org.uk/

   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:Where Extreme Programming Fails! (Score:1) by Woodie (woodward@shore.net) on Tuesday December 21, @10:52AM EST (#66) (User Info)

   Hmm, 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:Where Extreme Programming Fails! (Score:1) by stephend (slashdot@nospam.zx81.org.uk) on Tuesday December 21, @01:08PM EST (#121) (User Info) http://www.zx81.org.uk/

   I think a reasonable summary of my previous post would be "Now no matter how smart your people are, there is an upper limit on how complex a system they can comprehend." This means that on a small project with many technologies it has lots of points to recommend it. The peer review is good; the release early/often is good. With lots of technologies, integration is a major effort, so getting it working early and keeping it working is a good way to keep costs down. The project I was working on had more than forty people at its peak, and the specialisms (?) required in each technology were such that most people would have difficulty keeping track of more than a couple. Yes, it can work. No, it's not useless. But, to shamelessly steal, it's no silver bullet.

   Re:Where Extreme Programming Fails! (Score:2) by William Tanksley (wtanksle@unspam.ucsd.edu) on Tuesday December 21, @12:16PM EST (#103) (User Info) http://dolphin.openprojects.net/Omega

   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. -Billy

   Re:Where Extreme Programming Fails! (Score:1) by NateDawg on Tuesday December 21, @12:56PM EST (#116) (User Info)

   I agree. While I can definitely see a time and place for this methodology, it's not for everyone and it's not for every situation. In fact looking back on my last handful of projects I can't think of one instance where this technique would have helped in any way. I'm not trying to bash the ideas presented, I think they have some merit. Can we hear from the trenches at all? Anyone using this effectively? ~Nate

   Re:Where Extreme Programming Fails! (Score:1) by Martijn Meijering on Saturday December 25, @01:24PM EST (#217) (User Info)

   The proponents of XP do not claim that it is for everyone or for every situation. See http://c2.com/cgi/wiki?ExtremeProgrammingProjects for descriptions of projects using XP. I've been using XP in C++ for the last year and I think it's great. There are a couple of examples of XP in C++ on my home page (http://www.wi.leidenuniv.nl/~mmeijeri).

   Re:Where Extreme Programming Fails! (Score:1) by denormaleyes on Wednesday December 22, @12:41AM EST (#184) (User Info)

   I don't think it is necessary that everyone deeply understand all the parts of a non-small, complex system they are building. However, I've had occasion to work on several moderate to large projects (5 to 30 developers and dozens more testers, business requirements analysts, etc, usually interfacing with several other "island" systems so big and complex you can't understand them and have to rely on expert representatives for guidance) that started out with compartmentalized development. Some sort of high level design was created and individual developers where sent out to write small pieces (typically smallish C++ database applications) that were supposed to all work together to complete the big grand scheme. Usually the individuals end up working in a vacuum. Worst case is "grab records from here, do this logic, put results over here, and quit asking how it really works, just trust the design." Meanwhile, the business/Big Picture implications of "do this/do that" are not apparent to the individual coders. Meanwhile, the brutal reality is the Big Picture was just a sketch. It's not until integration time (hopefully) that you find some combination of coders making assumptions inconsistent with the Big Picture and instances where the Big Picture left out important cases. If the missing cases don't fall neatly in an individual coder's sandbox, then the problems sometimes see the light of production. Once your screw up is in production and supposedly firm deadlines are "succesfully" passed, you get to sit with all the other developers and tiger team solutions to all those broken assumptions that under production usage manage to blossom into failure, usually outside the scope of any one developer's code. This sometimes involves debugging complex interactions where you start to question whether any one system, be it database server, access library, widely-published-and-respected class library, aren't actually failing somewhere. Having several eyeballs and hypothesis generators can track down a problem with super-linear scaling up to about 5 people. (You also get to find which software vendors put out products that need more debugging than your own code.) In this "what went wrong?" phase, you finally learn how the system was supposed to work (the Big Picture), how it really works as coded, and what the Big Picture should have been. A small group of sharp developers can then brainstorm lots of ways to correct the problems, sometimes with ugly hacks, sometimes architectural modifications, and the occasional elegantly simple fixe. So long as the Big Picture's original authors aren't hung up on their (incomplete, buggy) plan being implemented as they dreamed it, you end with a much better, robust design. Unfortunately, you may have to also figure out how to (1) implement that design into a live system with as small an outage as you can afford and (2) clean up the data the wacky first release thoroughly messed up, often using throw-away code you'll only run once in production. With luck, your "really important" system wasn't as important as you were lead to believe. If we could have just gotten everyone together to let the developers in on the big picture, we would have been much better off with the first release. Understanding the Big Picture implications of what your code does is critical to the end result working well, especially when the test cases developed aren't capable of probing beyond the edges of design in the same way that real life users and unexpected derailments and failures can. Users in my organisation have come to expect any first implementation of a project to be a rough draft that will be transformed into something actually usable Very Quickly within a few weeks of release.

   Re:Where Extreme Programming Fails! (Score:1) by DonWells on Friday December 24, @02:44PM EST (#214) (User Info)

   Nice idea, but it wouldn't work in real life. The problem is that it doesn't work in theory, it does work in real life.

   Test-first seems good, but what about UI? (Score:0) by Anonymous Coward on Tuesday December 21, @10:35AM EST (#58)

   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?

   Re:Test-first seems good, but what about UI? (Score:1) by Zurk (zurk@SPAMSUCKSgeocities.com) on Tuesday December 21, @03:00PM EST (#148) (User Info)

   You might want to consider the automated test from 3Com's palmpilot emulator - the gremlin tests where automated inputs are fed to the UI randomly to see what breaks.

   Re:Test-first seems good, but what about UI? (Score:1) by Lister of Smeg on Tuesday December 21, @03:10PM EST (#150) (User Info)

   The general consensus is that it's better to unit test the model behind the UI rather than the view. Keep the view simple until the end and then you can use "screen scrapers". Remember that if any widget moves, your "screen scraper" test fails, so I wouldn't bother until I'm reasonably sure the GUI is relatively stable.

   Task Difficulty (Score:1) by ucblockhead (sburnapSPAMSUXlinux@attSPAMSUX.net) on Tuesday December 21, @10:40AM EST (#59) (User Info)

   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. Those who will not reason, are bigots, those who cannot, are fools, and those who dare not, are slaves. -George Gordon Noel Byron (1788-1824), [Lord Byron]

   Moderate this up please! (Score:1) by HarpMan (smolitor@erac.com) on Tuesday December 21, @12:51PM EST (#115) (User Info)

   Anonymous Coward writes: 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? I think this is a common problem. I don't know much about this myself, since I'm working on the middle-ware portion of a 3-tier project. But, at least on our project, the testing people always have trouble setting up automated regression tests for the gui. If someone changes the layout of the screen, all the old tests fail. I don't know if they're using the testing tool wrong, or what. Does anyone have any experience with this problem? -- Steve Molitor smolitor@erac.com "Emacs is the Computer" Stephen Molitor steve_molitor@yahoo.com

   Re:Task Difficulty (Score:1) by DonWells on Friday December 24, @12:50PM EST (#211) (User Info)

   What we found is that we were better off always working in pairs. It is all too easy to add unused functionality or subtle bugs when coding up iteration 5 because we are bored and we have a false sense of security. Or think of it this way. Your system is going to be 90% mundane code and 10% interesting. Do you want your sytem to be 90% low quality and 10% bug free? Program in pairs 100% of the time!

   Today's Buzzword is... (Score:1) by bhurt (bhurt@visi.com) on Tuesday December 21, @10:47AM EST (#63) (User Info)

   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. Brian

   Re:Today's Buzzword is... (Score:2) by William Tanksley (wtanksle@unspam.ucsd.edu) on Tuesday December 21, @12:21PM EST (#106) (User Info) http://dolphin.openprojects.net/Omega

   No, these are not code reviews -- they don't produce the documentation which code reviews do, and the documentation they DO produce is intended to document the entire project, not only the code quality. Code reviews are definitely cool, and with enough programmer mobility this would remove *some* of the need for code reviews. I would still want them, though; they provide another aspect of managability. I would also want to use RMMM reports with spiral lifecycle model. This also seems to combine nicely with a modified Surgical Team model. Of course, all I've done is the Refactoring part of XP -- but it alone was enormously effective. I can't wait to start pulling in more and more pieces from XP, and eventually start combining it with other proven methodologies. -Billy

   Re:Today's Buzzword is... (Score:1) by homunq (jquinn+slashdot@cs.oberlin.edu) on Tuesday December 21, @02:02PM EST (#140) (User Info) http://homunculus.dragonfire.net

   Is this a troll? Replying to an anti-buzzword message with 5 buzzwords (and another 5 pieces of managementese)... If you don't want to be modded down, guy, better at least give us links for that stuff. I'm just a real programmer, not a CS wonk, and I haven't even heard of half of your buzzwords. "Four years of college education had accomplished exactly what it was intended to—made her unsuitable for 90% of the work on this earth." -Song of Solomon

   Re:Today's Buzzword is... (Score:2) by William Tanksley (wtanksle@unspam.ucsd.edu) on Tuesday December 21, @03:11PM EST (#151) (User Info) http://dolphin.openprojects.net/Omega

   If you don't want to be modded down, guy Don't threaten, okay? Just ask. You had a good question, but this is just plain rude. An apology would serve you well. Anyhow... give us links for that stuff. I'm just a real programmer, not a CS wonk, and I haven't even heard of half of your buzzwords. No problem. RMMM doesn't matter (it's a detail of spiral development); look up Spiral Lifecycle Model in any decent SW engineering book. The closest one I have is "Rapid Development", and it does indeed discuss it. Code Reviews are a formal SW engineering practice documented at Univ. Hawaii's page. The Surgical Team model is one of the many memorable concepts discussed in Fred Brook's "Mythical Man Month". Read it. It's the #1 most recommended book by the Greats of CS and SW engineering. Refactoring is part of XP, and is documented best in the book titled "Refactoring". I highly recommend it; serious programming stuff there, no fancy-pants process requirements. XP is facinating because it tends to reduce the parasitic overhead of process. For example, no formal design documents are required with the exception of the user stories and the code. -Billy

   Save some cash.... (Score:3, Informative) by Rombuu (rombuu@surfree.com) on Tuesday December 21, @10:47AM EST (#64) (User Info)

   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:Save some cash.... (Score:1) by the eric conspiracy (rlarson-at-monmouth-dot-com by-the-sea) on Tuesday December 21, @11:02AM EST (#71) (User Info)

   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. This .sig no verb.

   Re:Save some cash.... (Score:1, Funny) by Anonymous Coward on Tuesday December 21, @11:12AM EST (#80)

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

   Another alternative (Score:1) by Esjion (alewis@crackcookies.com) on Tuesday December 21, @11:14AM EST (#82) (User Info) http://www.crackcookies.com

   If you are doing the whole amazon.com boycott thing but still want to save a few bucks, you can always try out bookpool.com . They are selling it for $23.50 , which is more than amazon.com, but that is unusual - they are typically cheaper than the other online places. I have used bookpool.com 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.

   Comparison shop (was: Save some cash....) (Score:2, Informative) by RocketJeff (jap@interaccess.com) on Tuesday December 21, @12:10PM EST (#101) (User Info)

   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 (Buy.com - out of stock) to $33.90 (Borders.com) (both are UPS ground prices). It's saved me a few dollars, now and then. Jeff

   Re:Comparison shop (was: Save some cash....) (Score:2) by William Tanksley (wtanksle@unspam.ucsd.edu) on Tuesday December 21, @12:23PM EST (#108) (User Info) http://dolphin.openprojects.net/Omega

   I'll vouch for BestBookBuys -- I generally use Amazon to look up reviews and do searches, then I copy the ISBN and paste it into bestbookbuys. Saves money and time. I'm not going to do any more reviews for Amazon, though; my reviews are now going to Fatbrain instead. -Billy

   Re:Comparison shop (was: Save some cash....) (Score:1) by sparcE on Wednesday December 22, @01:30PM EST (#197) (User Info)

   I win on the Amazon stuffing front. I ordered the book two months ago, then wrote Amazon an email telling 'em I'm boycotting their site because of their patent dispute. The book never arrived here in the United Arab Emirates (don't ask why I'm here), so now they're going to Fed Ex it to me express--it'll cost them a bundle. Good service, I must say. I'm still gonna keep boycotting them until they relent on the patent shit, though

   Re:Save some cash.... (Score:1) by HalB on Tuesday December 21, @10:37PM EST (#179) (User Info)

   If you want to save money AND still be principled, buy it for 19.97 at buy.com. Shipping is reasonable. http://www.buy.com/books/product.asp?sku=30549158

   where it fails (Score:3, Informative) by dutky (dutky@BellAtlantic.net) on Tuesday December 21, @11:02AM EST (#72) (User Info) http://members.bellatlantic.net/~dutky/

   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:where it fails (Score:1) by mayoff (mayoffslashdot@dqd.com) on Tuesday December 21, @12:38PM EST (#111) (User Info)

   I must ask, have you even read the XP book? The Mythical Man Month is a good book, but it's not gospel. It can be superceded. Regarding "debugging in pairs": you PROGRAM in pairs. Debugging is part of programming, but you do all your programming in pairs. You'll spend less time debugging because pair programming is equivalent to continuous peer review. You'll also spend less time debugging because comprehensive unit tests help prevent anyone from breaking code accidentally. Regarding throwing one away: XP doesn't foreclose the possibility of creating a prototype. However, XP is also all about constant redesign. Every programmer on the team has the responsibility of fixing the design if it's broken. Regarding unwarranted assumptions: XP requires that you change the way you approach requirements gathering and scheduling. But it's not about ignoring experience. It advocates avoiding doing work until you need it, but it doesn't say you should design yourself into a corner.

   Re:where it fails (Score:0) by Anonymous Coward on Tuesday December 21, @02:07PM EST (#142)

   Another point which the review fails to make but which the book does mention is the fact that it falls apart as the size of teams grows. The author does say that a small team works best, and that it won't work with anything larger than about 15 people. As the size grows, the book suggests breaking into teams to reduce the amount everyone needs to know.

   Re:where it fails (Score:0) by Anonymous Coward on Tuesday December 21, @10:33PM EST (#178)

   >no individual code ownership Yup. And thus, no accountability. I have a rule: your code screws up, you're responsible to fix it. Of course, when I screw up (and I do, though not very often), I fix it, on my time and at my expense. Without code ownership, this can't happen. Also, there is no pride of ownership with coding by committee. Finally, coding by committee results in coding at the level of the lowest common denominator, as it were. Not good. >new team members Mentoring is good, but expensive. Frankly, you've got to be able to hit the ground running in order to be productive and useful in a commercial project. In such an environment, mentors should serve the role of honing existing skills and not developing them from scratch. >debugging in pairs Useful for the tough problems, but too expensive to be used for every problem. You know when you need a different perspective. >unwarrented assumptions Yes. A rather artificial environment is assumed. Regards, Rene S. Hollan (posting anon cause I lost my account)

   Re:where it fails (Score:1) by SamesShuster (sames at interaccess dot com) on Wednesday December 22, @03:45PM EST (#203) (User Info)

   You have made a fundamental mistake. You have equated "No Individual Code Ownership" with "No Code Ownership." While this is a common mistake, it is not what XP professes. XP says there must be Communal Code Ownership. Instead of "Individual Code Ownership" where it's "My Code vs Their Code (And I'll do everything in my power to protect MY code from 'Them', those morons)", there is just "Our Code!" The pride you speak of is cowboy pride. Pride in keeping my code working while all of the other morons screw up. It's the pride that leads to "Well, MY code worked!" How sad. Worse... it is frightfully pervasive. There is another pride possible. "Our Code Works", and "I Contributed To Making Our Code Work", and "I Was Successful In Helping Our Project Be Wildly Successful!" I have personally always found the former to be shallow and ultimately, unproductive, while latter to be the only truly satisfying form of pride I have ever experienced. And So It Goes Sames

   practices that succeed (Score:2) by Lumpish Scholar (psrchisholm@yahoo.com) on Wednesday December 22, @02:05AM EST (#186) (User Info)

   Caveat: I was one of the technical reviewers of the book. (Yes, Kent misspelled my name.)-: I see some big problems with the technique: There are concerns about when and how to apply XP (Kent raises some of them in the book), but your response based on the review is off base. I haven't "done" XP; I have successfully used some of the practices Kent calls for as part of XP. Here's my experience on how some of those practices work. 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 No. Lack of individual code ownership is one of the extreme practices, but neither of your deductions is correct. The design is fluid (as it is with any working method); no one is forbidden from making changes (there's no code only I can touch), but no one [pair] makes changes without understanding the code as proven by the fact that their changes must pass the existing unit tests and must be supported by additional unit tests created before or at the same time as the changes. Lack of code ownership is controversial. I work in a project with a couple hundred thousand lines of code, and half a dozen programmers, that makes it work just fine (not using XP). I work alongside a much larger project, with hundreds of programmers, that also works that way. 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. By pairing new members with more experienced members. (The new member "drives" most of the time, so the information flows through him or her; he/she's not watching, but doing.) debugging in pairs is a good idea, and should be used by any programming team that has the personnel to spare No no no no no no no. Programming in pairs is *not* just about debugging, and is NOT about "spare" staff. When it works, two people programming (designing/ coding/ testing/ debugging) in pairs work faster than the two individuals working together ... often much faster. XP (and refactoring, as described in a book reviewed here a few weeks ago) calls for generating huge numbers of unit tests, completely automated, that can be run at the push of a button, and which are run several times per hour by each pair. That's where your coverage comes from. design to throw one away ... A methodology that doesn't address the need to redesign ... XP calls for continous refactoring of the system "to work around mistakes and compromises made when" developing, not disposable prototypes, but earlier versions of the system. Most programming projects don't have the latitude to set prices for each feature Each feature will take as long as it takes. XP suggests ways a project can learn how to better estimate these "prices", and spell them out for the customer. Any project, XP or not, where the customer says, "You say this will take six weeks, but I need it in one, so you'll have it in one week," is doomed anyway.

   Re:where it fails (Score:1) by DonWells on Friday December 24, @02:28PM EST (#213) (User Info)

   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. Exactly so. That is why Extreme Programming advocates most design is done by two people working together. Only major design decisions are made by more than two people at a time. individual code ownership minimizes the need for communication across the entire group Which is why it should be avoided. When no one on the team is communicating and working together the resultant system will be an incoherent mess. this technique is almost certain to fail for any group larger than a half dozen or so. As the book states, it is only good in small groups. It has been used with 10 developers successfully. Remember that sometimes a small group working well can produce more than an army working at cross-purposes can. new team members... Please read the book first. But since you asked pair programming brings new team members up to speed. The system is shown and explained to new team members piece by piece, line by line. 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). no, No, NO! Read Kent's book. Debugging time is reduced to a fraction of what it would otherwise take. Writing a unit test is not the same as debugging. Every time I write a unit test I save myself some debugging time tomorrow, next week, next month, and even next year. That adds up to significant savings. design to throw one away... no, No, NO! Read Kent's book. You always create a prototype called an architectural spike and then throw it away. It is built into the methodology unlike most other methodologies. XP is the only methodology that I am aware of that does address changing the base architecture of a system running in production. Most programming projects don't have the latitude to set prices for each feature, or even to pick and choose which features to implement Surprisingly enough they actually do. But you have talk to your users and/or customers and assume that you don't know more than they do before this becomes apparent.

   customer rep sits on his ass (Score:1, Insightful) by Anonymous Coward on Tuesday December 21, @11:23AM EST (#85)

   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:customer rep sits on his ass (Score:1) by RobertEdwards on Tuesday December 21, @11:33AM EST (#89) (User Info) http://www.nashville.com/~robert.edwards/index.htm

   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.

   Re:customer rep sits on his ass (Score:0) by Anonymous Coward on Tuesday December 21, @12:08PM EST (#100)

   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.

   Not in this case (Score:1, Insightful) by Anonymous Coward on Tuesday December 21, @12:33PM EST (#109)

   "Ummm...maybe the developers were wrong" Not in this case. The application was a VR training simulator, and definitely isn't the sort of system that "evolves" as the client uses it, like yours. The developers had a much better idea of how long certain features would take to implement, and why it would be better to put more planning into various features and less into others. The client had no such concept, in his mind, when he asked for some ridiculously complicated feature, it was "why can't you just quickly add it?". The other similar, related problem was that he kept nagging for new features that weren't originally quoted for and thus weren't in the spec for version 1; he was asking for more than they had paid for. In some cases we gave him extra features, but at a point we had to say no, because they were dragging development out and interfering with schedules. Many features you simply cannot "just quickly add".

   XP was designed for exactly that situation! (Score:2) by cpeterso on Tuesday December 21, @01:49PM EST (#137) (User Info)

   Extreme Programming (XP) is supposed to be an ongoing dialog between "Business" (the "Client") and Development. If the client wants a new feature, the developers need to introduce the Client to the "Software Triangle" (Cheap, Fast, or Good: choose two). Clients are paying for the software, so they should get what they are willing to pay for. If a client wants a new feature "quickly", the Developers give the client a revised time and cost estimate for the added feature. Developers are good at deciding how long something will take to implement. Clients are good at deciding whether they want to invest the time and money for that feature, once they know how long the feature will actually take to write. chris

   Re:Not in this case (Score:0) by Anonymous Coward on Tuesday December 21, @04:08PM EST (#159)

   Okay, I sympathize. That does kinda sound like a nightmare. Even on our application there have been times when we've had to say "no," and other times when enhancements were sold that really took us developers off track.

   Gerald Weinberg: Psycology of Computer Programing (Score:2, Funny) by Anonymous Coward on Tuesday December 21, @11:32AM EST (#88)

   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:Gerald Weinberg: Psycology of Computer Programi (Score:1) by BillWhite on Tuesday December 21, @01:31PM EST (#132) (User Info)

   For some reason this book reminded me of Gerald Weinberg's ancient tomb. Esp the advocacy of very small teams. What's this? Is Gerald Weinberg dead? Or is he simply alive writing less ancient tomes?

   re: guys/girls/pair coding (Score:1) by chocolate pi on Tuesday December 21, @06:34PM EST (#165) (User Info)

   As a female college student in a dorm where people wander aimlessly in and out of each others's rooms, I find that the best way to get any coding project done is to leave it up on my monitor and wait for a critical mass of male compsci majors to come in and start arguing about it; it's the most time-consuming way, but it definitely provides enough options as one guy goes for elegance, another for obfuscation, another wants to write it all in another language ... The dibble is rusty.

   Extreme Programming! (Score:1) by SydBarrett (sydb@glue.umd.edu) on Tuesday December 21, @11:37AM EST (#90) (User Info) http://www.wam.umd.edu/~sydb/yarpage.html

   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! SURGE! (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) Yes, I'm one of the Founders of Yarism. http://www.wam.umd.edu/~sydb/yarpage.html

   Mountain Lightning... (Score:1) by Svartalf (fearl@!spammers!die!airmail.net) on Tuesday December 21, @12:39PM EST (#112) (User Info) http://members.xoom.com/svartalf

   Yep, I live on that stuff. One of the higher caffene drinks out there- and it's cheaper than everyone else's stuff. "All we are is dust in the wind..." -- Kansas, Dust in the Wind

   Re:Extreme Programming! (Score:1) by WinTired (docemaior@zipmail.com.br) on Tuesday December 21, @01:16PM EST (#125) (User Info) http://www.jesus.oliveira.com

   Wasn't the Altair 8080-based?

   Re:Extreme Programming! (Score:1) by Gomez on Tuesday December 21, @03:58PM EST (#158) (User Info)

   The Altair 8800 was based on the 8080 microprocessor. Having a model number so similar to the CPU name didn't help.

   A personal experience... (Score:3, Insightful) by William Tanksley (wtanksle@unspam.ucsd.edu) on Tuesday December 21, @12:03PM EST (#98) (User Info) http://dolphin.openprojects.net/Omega

   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. -Billy

   Have the scoffers actually tried coding like this? (Score:3, Interesting) by vivarin on Tuesday December 21, @12:17PM EST (#104) (User Info) http://www.well.com/~gavin

   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.

   XP works for me. (Score:1) by emeade on Tuesday December 21, @12:37PM EST (#110) (User Info) http://www.geekfarm.org/emeade/index.html

   I ran into XP via Cunningham & Cunningham, Inc.'s ExtremeProgrammingRoadmap. I had a lot of the same thoughts that many here have posted, with tons of reasons why it couldn't possibly work. I decided to use some of the XP methodology for some tutorials and samples I needed. I will never look at programming the same again. If you have some extra time I would suggest buying the book, opening your mind, and doing some extreme programming. It has changed my life, it might change yours. The way would not exist if not for the laughter. The truth, it won't set you free, but it gives you someone to blame....

   Design Patterns (Score:2, Interesting) by Corrinne Yu (corrinney@3drealms.com) on Tuesday December 21, @01:22PM EST (#129) (User Info) http://www.3drealms.com

   Disclaimer : I hope I do not offend Design Pattern purists in my following loose interpretation of DP. I merely attempt to attribute my own ideas to others. If the following ideas deviate too greatly to be called DP, then I am grateful I have actually formulated or described something original. There are many threads above that argue vehemently against and for a non-written-spec-based development pattern, "hacking" so to speak. What makes a great project, and makes for great programming, is not the *winner* of the paradigm or design pattern. It is not something as simple as "OO rulez", or "Pedal to the Metal." A great project, and a great programming team, distinguishes itself by the proper choice and appropriate use of paradigms and patterns. // Flame Bait Alert Begins Zealous proclamations like "Never have multiple function exit points", "Never use gotos" and "Never have modules exceed N number of lines" often stem from *inexperience* that never had such proclaiming coders be *forced* into such circumstances when breaking such rules lead to easier to read or more maintainable code in the long run. // Flame Bait Alert Ends Many development books and paradigms are written as if code and programs are created in perfect sanitized heavens that I have yet to experience in any game development house. On the flip side, there are many game programmers or *hackers* who can so glibly discard decades worth of language or system theory research, and sincerely believe they can create thought systems of equal robustness in a matter of months. We do not need more flame throwers. We need accessible information and research to cloistered practitioners like us. And we need to contribute back to academia codified and scientific "development patterns" we corroborate with our colleagues/competitors so the system of knowledge can "grow" instead of "treadmill." Post-mortem's and magazine articles, even interviews, are good baby steps. But our field needs something more scientific and codified than that. We need to know not only what fails and what works. But what works in "which circumstances." What fails in "which other." Lots of lots of redundant information to prove one way or otherwise. In retrospect, what I describe is more "development" pattern than "design" pattern. I would greatly appreciate if fellow posters and programmers can point to me, or discuss from personal experiences, various "development" patterns that work, and various that fail. The most enlightening discussions would be given the same "development" pattern, one that succeeds in one circumstances, and fails in another. Then is the failure based on inappropriate circumstances, or improper application? A more informative discussion is not "this paradigm fails" "this paradigm is god" but how which paradigm best works in which circumstances. I hope to see from now on discussion goes more in that path. Apologies of diverging from the topic of the specific book. Disclaimer : If you are inclined to respond in flames, please at least first re-read what I am really saying. Thank you. Corrinne Yu 3D Game Engine Programmer 3D Realms/Apogee Corrinne Yu 3D Game Engine Programmer 3D Realms/Apogee

   Re:Design Patterns (Score:0) by Anonymous Coward on Tuesday December 21, @09:28PM EST (#175)

   You're very intelligent. Can I date you? I've always wanted to date an Asian, intelligent 3d game engine programmer, and I'm not kidding. Let me know what you think babe.

   Re:Design Patterns (Score:1) by veldrane on Tuesday December 28, @02:01PM EST (#225) (User Info)

   Ok...so I've been a little slow on the response but I do have a few comments. (and no, I am not the AC that was asking you for a date...I'm not that brave >;) As for the comment about goto usage, I remember one of my old professor's feelings on that matter. It usually involved him painstakingly write the goto statement on the board (and he did a very good job of making it look like it was causing him great pain) followed by a very quick erasure. Like most everything, there is a good way and a bad way to use gotos/jumps/whatever. The idea is to write "good" and readable (as possible) code so that anyone that has to make mods/fixes to your code (which could be you at a later date) or anyone that has to perform a code review can do so without a lengthy time deciphering. [Job] Security through Obscurity just doesn't work. Well, sometimes it does. >;) As far as development plans (I hope I'm talking about the right thing here...) in what works and what doesn't in various situations I can say from experience that I have been in a few different dev environments one namely being with Trilobyte's end days as a game development house. (how I miss those days... :( One of the most important aspects of a development house that deals with cutting edge technology in a highly creative environment is the mental state of the programmers/artists (since in thise case, programming really is an artform as well). Sometimes the smallest things can have very serious change. Of these, the most noted that I recall is the effect of the publisher's behavior and actions. The game development I was part of wasn't "Here's the book, could you publish this?" It was more like, "Here's the gist of the story and a rough outline, can you pay us to write it for you?" The bad thing about this is that this puts the publisher in more control of what goes in the story. Instead of seeing a finished product, they interpret a finished product from the framework that can be quite different than the acutal authors. They can (and do) itemize the expense based upon features and this sets up a milestone type of development environment. Things like improper milestones can cause the dev team to insert "fluff" just to get that next paycheck, only to lose valuable time creating the "fluff" and removing it again just because the dev process doesn't match the milestones. Things like this can cause a chain reaction of stress and "catch-up" that can destroy a project and or the dev team. Milestones can be a good thing though when a strict set of rules are already in place for the flow of the process. Personally, this is a financial view of the waterfall process where you assume that at each checkpoint, everything done beforehand is finalized and unchangeable. Any slight change in the specs (which the publisher want to reserve the right to!) can throw this process out of whack and force the development to backtrack, quite possibly to the very beginning! Funny thing is, no changes to the budget needs are made to reflect this. (or if they are, I haven't seen any.) If there is a good path/specs and the assumption that everything finished at each point is final and unchangeable, this is a viable process. Personally, I like a more object-oriented or iterative path for this type of development with such a high level of creativity. This process generally starts out with something small or simple, like the formation of the idea. Some of the artwork will be placeholder material and the the coding is not too complex. The basic building blocks of the project are designed and formed here. This is followed by a testing/evaluation phase which verifies that things are good (and which aren't) at this point. the next step is to look at the project and decide what things need revising and what features could be added. The project's features/fixes are divvied handled by the team in the next session. Now, some of the building blocks are more stable, more defined. Some new blocks have been added to the equation (but not too many!) and perhaps some of the art is a little more definitive to give a better impression of the path of the project's development. This is followed by the testing/evaluation and the process is repeated. This is a very good model (IMO) that allows changes to specs at any point in the process so that parts can be revised, removed, etc without serious (hopefully) damage to the project as a whole. It's kind of like Newton's Method for finding roots, etc. It can get closer and closer to the goal, provided some unexpected factors don't kick in and really shake the system, such as major staff changes. Well, feel free to correct/disagree with anything I have said...flames aren't appreciated and generally ignored since I don't take too kindly to opinions about my personal life...I don't have much use for flame wars. I'd write more but I'm not into writing novels yet. >;) -Vel

   Respect for the author (Score:1) by smalltalker (cline@acm.org) on Tuesday December 21, @01:26PM EST (#131) (User Info) http://www.objectbap.com

   For those who don't hang around the relativly small community, Kent Beck is a Smalltalk God (tm). Any list of the 5 most influential Smalltalkers would include his name, so I put a lot of stock in his work. He is also very infuential in the Patterns community, such as his contributions to the Portland Patterns Repository. Working with Ward Cunningham, he came up the CRC Card design method, which is the only "design methodoligy" I find I really use. Someone once wrote that his list of recommended Smalltalk books starts with 'anything by Kent Beck', and his "Smalltalk Best Practice Patterns" is the definitive work for tactical programming patterns for that language. Steve Cline Object Bodies & Parts, Inc. http://www.objectbap.com

   A Reason to like XXTreme PProgramming. (Score:2, Funny) by BillWhite on Tuesday December 21, @01:32PM EST (#133) (User Info)

   If you pair programmers in the same cubicle, with only one computer between them, you don't have to worry that one or both of them are wasting their time reading and replying to Slashdot articles.

   not to get into an amazon.com flame-trap, but... (Score:1) by Misha on Tuesday December 21, @03:40PM EST (#156) (User Info) no web page

   the book is actually cheaper there than at fatbrain. ridiculous one-click copyright lawsuits aside, amazon.com is still a pretty good place to buy the byproducts of growing trees. here is the link to the book. p.s. i wonder if they are going to sue me for providing a "one-click" method of getting the book at their site. hmm... perhaps even linking is illegal... oh, well, enjoy you new year's!!! "The lunatic is in my head." --Pink Floyd

   Re:not to get into an amazon.com flame-trap, but.. (Score:1) by HalB on Tuesday December 21, @10:39PM EST (#180) (User Info)

   Cheaper still at buy.com. http://www.buy.com/books/product.asp?sku=30549158

   programming in pairs (Score:1) by ixo on Tuesday December 21, @04:35PM EST (#160) (User Info)

   i think having someone look over my shoulder while i code would drive me insane

   Re:programming in pairs (Score:1) by BigTom (tom@novikings.lynch-fm.demon.co.uk) on Wednesday December 22, @02:22AM EST (#188) (User Info)

   If they are just looking over your shoulder then you are not pair programming. During a pair programming session both developers are fully engaged. Tom "It's not what you know that kills you, it's the things you know that ain't so." - Mr. Tompkins

   ACM Programming Contest (Score:1) by DMuse on Tuesday December 21, @06:16PM EST (#164) (User Info)

   It might be interesting to note that the ACM programming contest is entered by teams of three. I have not competed myself but my understanding is that it is normal for one competitor to be entering the solution for one problem while the second competitor checks over the shoulder. The third competitor is working on the next problem. It would be interesting if their was anyone who knew what the ACM's reasoning is for having teams of three.

   XP Is Engineering (Score:1) by PeterAtWebsense on Tuesday December 21, @07:06PM EST (#168) (User Info)

   XP is nothing but engineering. Highly disciplined engineering, SEI CMM Level 5 Engineering. It's repeatable, it records, it measures, it optimizes, it plans software development in exquisite detail. XP is a painstaking and rigorous process that is simultaneously paper-light and stress-free. Anyone who disagrees with these statements simply doesn't understand XP. Plainly most of the correspondents here simply don't understand XP. Beck's work fundamentally advances the state of the art in Software Engineering, and his book is at least as important as Design Patterns. Where Beck has failed is in anticipating the outrage of all you shmoes. Beck's book is obviously failing in communicating the idea that XP is *NOT* Cowboy Coding. If you think it is, get the book, read the book, understand the book. And then you'll probably want to try it. And then you'll understand, but that'll be too late to quench the flames. Still, isn't this a risky way to evaluate the XP approach? Well, look at it this way: over half of the world's software projects fail outright. So far there are no known XP projects that have failed. None. So what have you got to lose? Besides, the whole thing is vastly more fun than you've ever had programming in teams. Quit yer yammering and give it a chance. And if you're too cheap or lazy to buy the book, most of the material there is also out on the wiki-web. Most of the XP boffins hang out on wiki - go raise hell with them there and you'll find that all the questions here have been answered in detail. XP is not programming without engineering. XP is engineering without therbligs.

   XP is NOT CMM Level 5 (Score:0) by Anonymous Coward on Tuesday December 21, @11:16PM EST (#182)

   CMM lays out quite rigorously and explicitly the practices one must undertake to be "Level 5". I'm not saying that XP projects can't attain this level, but it certainly isn't a necessary result either. XP is (thankfully) far less verbose than Humphrey's CMM.

   XP is enough CMM Level 5 (Score:0) by Anonymous Coward on Friday December 24, @10:13PM EST (#215)

   XP achieves everything CMM Level 5 calls for, except killing large numbers of trees. If XP's not Level 5, it'll do until something that is Level 5 becomes practical. See Ron Jeffries' XP CMM comparison for more reasons to think XP is what's worthwhile about Level 5.

   XP Pain? (Score:1) by HalB on Tuesday December 21, @10:13PM EST (#177) (User Info)

   I could see this being very painful if the person you're swapping out with is not capable with a decent editor or is a really slow typist. I know this has been one of my pet peeves when programming in pairs/groups in the past.

   summary of XP (Score:2) by Lumpish Scholar (psrchisholm@yahoo.com) on Wednesday December 22, @02:27AM EST (#189) (User Info)

   Caveat: I was one of the technical reviewers of the book. (Yes, Kent misspelled my name.)-: Funny coincidence: I got my copy of the book Tuesday, just about exactly when the review was posted at Slashdot. I can't find fault with anything in particular with the review, but to me it doesn't capture what makes XP so, um, extreme. Here's my take. XP is a lightweight, high discipline method (to quote Alistair Cockburn). You don't write a lot of documents; no "Victorian novel" requirements boat anchors. What you do, you do all the time; no "cowboy coders" (despite what you might guess from this or other reviews). What you do in XP: o Programming in pairs: No one designs, codes, tests, or debugs by themselves. There's an incredible gestalt you can take advantage of; if you've done it, you know what I mean. (If not, read the book.) o Unit tests: Hundreds, thousands of them, more every time you make a change, run several times an hour, all available at the touch of a button. The idea is to save time, not spend it; if you make a mistake, the unit tests have a good chance to find it fast. o Refactoring: Don't design or code your system to do what you think it might do; instead, implement the features you're working on currently, but be willing to go back and refactor it (make big changes) "just in time". You're not making the smallest, simplest change each time; that leads to the evolution of unmaintainable dinosaurs. Instead, you're creating the smallest, simplest system that does what you need it to do, even if that's big time different that the smallest, simplest system that does what you needed last week. (How can you be sure you didn't break anything? Hit that "unit test" button, early and often.) o Low tech project management. Break the project down into "user stories" (use cases); track the estimates and actual time for each; learn what your project's "load factor" is, and how to improve your future estimates. Gantt chart weinies need not apply. o Short development intervals; incremental releases every few (two to six, often) weeks. Avoid the "90% done" disasters. Yes, this is in the spirit of what Grady Booch calls "spiral development." (Does anyone still think they're following the "waterfall" model???) o Teamwork. Kent doesn't say so, but XP's not likely to work for programmers who punch a time clock (though he strongly encourages working only eight intense hours a day and then going home!) XP is a very new method. There's not a lot of track record, sucesses or failures, out there yet. Consider it for a project with three to ten developers and the need for having something minimal working fast, and more features on a regular basis after that. (Read the book first!) Don't bet your next hundred developer project on it ... not yet, anyway.

   Re:TROLLMASTAH THE JERK (Score:0) by Anonymous Coward on Tuesday December 21, @09:14AM EST (#4)

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

   Re:TROLLMASTAH THE JERK (Score:0) by Anonymous Coward on Tuesday December 21, @09:26AM EST (#10)

   > hehehehe, gawd I'm so fucking funny!! No, no you're not. Okay, so you feel encouraged by this response? Shame on you.

   Trolling v.s. Flamebait. (Score:0, Insightful) by Anonymous Coward on Tuesday December 21, @09:25AM EST (#9)

   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.

   Moderator (Score:0) by Anonymous Coward on Tuesday December 21, @09:44AM EST (#24)

   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)

   [OFFTOPIC] Re:Moderator (Score:1) by El Volio (elvolio@yahoo.com?subject=slashdot) on Tuesday December 21, @11:43AM EST (#92) (User Info) http://slashdot.org

   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. -- "You can never have too many elephants on your team."

   Re:Moderator (Score:1) by questor (questor@mediaone.net) on Tuesday December 21, @01:16PM EST (#126) (User Info)

   Everyone is entitled to an *informed* opinion. Since you have not yet read the book or the web sites that have been listed, your opinion is not yet an informed one.

   Informed opinion (Score:0) by Anonymous Coward on Tuesday December 21, @02:31PM EST (#145)

   Since you don't know what I have or have not read, your opinion is also uninformed. But I would not be so arrogant as to state that your opinion doesn't matter because it is uniformed. The reason your opinion doesn't matter is that it is hypocritical.

   Re:Trolling v.s. Flamebait. (Score:1) by rent on Wednesday December 22, @02:18AM EST (#187) (User Info)

   I think here at slashdot Troll is used to defame the user that made the comment, and Flamebait is used to defame the actual comment more than the user. This is because 'Troll' is an insult. If you call someone a Troll, you hope to hurt their feelings. The reason why you want to hurt them, is because of the reasons given in the post above - usualy because the the person posted a comment that showed arrogance or the wrong facts. Usualy trolls are people that dislike linux. Meanwhile flame bait is branded to a comment when the comment goes againts the general values / ideas. Usualy moderators brand flaimbait to comments where the poster mentions windows in a positive sence

   Re:TROLLMASTAH IS THE KING (Score:0, Troll) by SkyWriter on Tuesday December 21, @09:49AM EST (#29) (User Info)

   Finally a breath of freshair! HOORAY!