Slashdot | Extreme Programming Explainedvar adpage = 'article'; dfp_ord=Math.random()*10000000000000000; dfp_tile = 1;var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src="http://slashdot.org/books/99/12/21/097256.shtml/" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));var pageTracker = _gat._getTracker("UA-32013-5");pageTracker._setDomainName("slashdot.org");pageTracker._initData(); Stories Slash Boxes Comments Slashdot Search News for nerds, stuff that matters Log In Create Account Help Subscribe Firehose Why Log In? Why Subscribe? Log In Nickname Password Public Terminal [ Create a new account ] Sections Main Apple AskSlashdot Books Developers Games Hardware IT Idle Index Interviews Linux Mobile Politics Science Technology YRO Help FAQ Bugs Stories Old Stories Old Polls Topics Hall of Fame Bookmarks Submit Story About Supporters Code Services Jobs Special Offers Sponsor Solutions Slashdot Log In Log In Nickname Password Public Terminal [ Create a new account ] Related Links Review IT ProductsCompare pricesCompare prices on BookschromaticfatbrainMore News stories More Book Reviews stories Also by Hemos Extreme Programming Explained Posted by Hemos on Tue Dec 21, 1999 09:10 AM 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. Extreme Programming Explained author Kent Beck pages 179 publisher Addison Wesley, 09/1999 rating 7/10 reviewer chromatic ISBN 0201616416 summary Extreme Programming Explained explains the virtues of the Extreme Programmer and shows you how to develop them. The HookWant 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 WrapupIf 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 The Problem Risk: The Basic Problem A Development Episode Economics of Software Development Four Variables Cost of Change Learning to Drive Four Values Basic Principles Back to Basics The Solution Quick Overview How Could This Work? Management Strategy Facilities Strategy Splitting Business and Technical Responsibility Planning Strategy Development Strategy Design Strategy Testing Strategy Implementing XP Adopting XP Retrofitting XP Lifecycle of an Ideal XP Project Roles for People 20-80 Rule What Makes XP Hard When You Shouldn't Try XP XP at Work Conclusion [+](tagging beta) This discussion has been archived. No new comments can be posted. Extreme Programming Explained | Log In/Create an Account | Top | 222 comments (Spill at 50!) | Index Only | Search Discussion Display Options Threshold: -1: 222 comments 0: 222 comments 1: 190 comments 2: 62 comments 3: 11 comments 4: 1 comments 5: 0 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads) The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way. Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference. (1) | 2 | 3 I much rather like sole systems by Rurik (Score:2) Tuesday December 21 1999, @04:22AM end user v. manager feedback (Score:3) by Pfhreakaz0id (82141) on Tuesday December 21 1999, @04:25AM (#1456210) I like the part about customer feedback (i.e., end user feedback). That is often hard to come by in projects I work on. The tricky part is balancing it with management feedback. A typical situation is one where the users of the software want ultimate flexibility, but management wants software that adheres to certain business rules. As in "you can't set a ship date for whatever you want, it has to be within five weeks of the order date." BTW, all this is from the perspecitive of "business apps," which some twit said wasn't "real programming" here a while back. Whatever. Re:Recipe for Disaster by Herkemer (Score:1) Tuesday December 21 1999, @04:27AMcost? by DGregory (Score:2) Tuesday December 21 1999, @04:29AMAhead of my time by Relic of the Future (Score:2) Tuesday December 21 1999, @04:29AMRecipe for Success by thanz (Score:2) Tuesday December 21 1999, @04:29AMPlanning is good! by Woodrow (Score:2) Tuesday December 21 1999, @04:29AMExtreme Programming not so extreme by Anonymous Coward (Score:2) Tuesday December 21 1999, @04:34AM Sounds Promising (Score:3) by Anonymous Coward on Tuesday December 21 1999, @04:34AM (#1456219) This method sounds like a programming corollary to the Cabal [gamasutra.com] system of design. (The method used to design Half-Life.) If it's anywhere close to being as effective, it's definitely worth a look. Pair programming works!!! by Da VinMan (Score:2) Tuesday December 21 1999, @04:35AMWhat is the "engineering phase"? :) by GoofyBoy (Score:1) Tuesday December 21 1999, @04:37AMIt's not bad at all by greendot (Score:2) Tuesday December 21 1999, @04:38AMIt's NOT extreme, just practical by Da VinMan (Score:2) Tuesday December 21 1999, @04:39AMLibrary Coding Tip by Eamonn O'Synan (Score:2) Tuesday December 21 1999, @04:42AMExtreme programming by VAXGeek (Score:1) Tuesday December 21 1999, @04:44AMDoes this book seem to be pushing a BAD idea? by GoofyBoy (Score:1) Tuesday December 21 1999, @04:44AMRe-writing code costs more-do it right 1st time by Da VinMan (Score:1) Tuesday December 21 1999, @04:45AMRe:It's not bad at all by Woodrow (Score:1) Tuesday December 21 1999, @04:46AMRe:Recipe for Disaster by bbutton (Score:2) Tuesday December 21 1999, @04:46AM... by Anonynous Coward (Score:1) Tuesday December 21 1999, @04:51AMRe:Recipe for Disaster by johnburton (Score:1) Tuesday December 21 1999, @04:52AM Spiral rehash? (Score:3) by Mr Neutron (93455) on Tuesday December 21 1999, @04:54AM (#1456234) This sounds much like the "sprial" lifecycle model, which has been around for some time. Risk management is very important, and with the spiral model you want to identify the risky-but-critical parts of the project and tackle those early. If you can't implement those critical areas, your project isn't going anywhere. Comments about user feedback are right on the money. Frankly, if you're developing a mission-critical app and you *don't* have constant feedback from the users during development, you're asking for failure. Software engineers aren't domain experts, and we will screw it up we lock ourselves away from the users. Yes, you'll have management constraints but you must always present options to the user. "We can implement the 100% solution using X time/money, or we can give you the 80% solution in X/2 time/money and also have resources to attack Y and Z. You pick." Neutron Re:Does this book seem to be pushing a BAD idea? by Anonynous Coward (Score:1) Tuesday December 21 1999, @04:54AMRe:Pair programming works!!! by pieguy (Score:2) Tuesday December 21 1999, @04:55AMRe:Recipe for Disaster by The Variable Man (Score:2) Tuesday December 21 1999, @04:57AM Re:Planning is good! (Score:3) by devphil (51341) on Tuesday December 21 1999, @04:58AM (#1456238) Homepage 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! by johnburton (Score:2) Tuesday December 21 1999, @04:59AMRe:cost? by richieb (Score:1) Tuesday December 21 1999, @05:02AMRe:I much rather like sole systems by pieguy (Score:2) Tuesday December 21 1999, @05:03AMRe:Planning is good! by Woodrow (Score:1) Tuesday December 21 1999, @05:04AM Extreme Programming web site (Score:4) by dsplat (73054) on Tuesday December 21 1999, @05:05AM (#1456243) I can't believe that no one else has posted a link to the Extreme Programming web site [armaties.com] 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. Too many eyes (Score:3) by dmorin (25609) <dmorin@Nospam.gmail.com> on Tuesday December 21 1999, @05:06AM (#1456245) HomepageJournal Reminds me of a time back in college when three of us were assigned projects in an AI class. One guy had no experience, so he did nothing. Two of us spent all nighters working on the code. One night, around 4am, our Lisp code wasn't working and we were stuck. We'd stared at it for hours, no luck. "Wait a second!" shouted my partner, leaning over my shoulder and beginning to type. "WHAT?" I asked, watching him move the cursor. He cursored over to a piece of Lisp code, and pressed the space bar. "Sorry," he said, "That was bugging me. Now it's indented properly." Re:Planning is good! by johnburton (Score:1) Tuesday December 21 1999, @05:06AMRe:Planning is good! by Woodrow (Score:1) Tuesday December 21 1999, @05:07AMRe:It's not bad at all by aeonek (Score:1) Tuesday December 21 1999, @05:08AMCommunication and Specification by adimarco (Score:2) Tuesday December 21 1999, @05:11AMRe:Planning is good! by Woodrow (Score:1) Tuesday December 21 1999, @05:12AMRe:Planning is good! by udin (Score:2) Tuesday December 21 1999, @05:12AMRe:Planning is good! by Woodrow (Score:1) Tuesday December 21 1999, @05:18AMRe:Planning is good! by johnburton (Score:1) Tuesday December 21 1999, @05:22AMRe:Planning is good! by Woodrow (Score:1) Tuesday December 21 1999, @05:28AMAlso look at "The Pragmatic Programmer" book by Woodrow (Score:2) Tuesday December 21 1999, @05:31AMRe:cost? by pieguy (Score:2) Tuesday December 21 1999, @05:32AM Where Extreme Programming Fails! (Score:3) by stephend (1735) on Tuesday December 21 1999, @05:33AM (#1456258) Homepage While I can see it working well in a number of circumstances, most of the projects that I've worked on it wouldn't work very well. Project type 1 where is wouldn't work is any large project, say over fifteen developers (plus management). Any system that big and complex will not be understandable by everyone. Cross-fertilisation is a nice idea, but when things get too complex you need an expert or a keeper. I guess you could have several experts, but you come up against the cost aspects very quickly. Project type 2 are those with varying technologies. One I worked on recently used Oracle, Unix, NT, LotusScript (Domino), NotesPump, VBScript, JScript and HTML. I would argue that you can't be an expert in all of them. I do Oracle and Unix and have an appreciation of the others, but I couldn't really add much when I reviewed the work in other teams. Again you could switch around each team once in a while, but any good team-leader would do that if they could anyway. And that's before you even get into the 'egoless' bits, and the fact that management like people to be responsible. How can you have a scape-goat if it's everyones fault?! Anyway, that's enough. Nice idea, but it wouldn't work in real life. Re:Recipe for Disaster by jormurgandr (Score:1) Tuesday December 21 1999, @05:33AMTask Difficulty by ucblockhead (Score:1) Tuesday December 21 1999, @05:40AMRe:What is the "engineering phase"? :) by JordanH (Score:2) Tuesday December 21 1999, @05:40AMRe:Extreme Programming web site by Anonymous Coward (Score:1) Tuesday December 21 1999, @05:41AMRe:Recipe for Disaster by loki7 (Score:2) Tuesday December 21 1999, @05:42AMToday's Buzzword is... by bhurt (Score:1) Tuesday December 21 1999, @05:47AM Save some cash.... (Score:3) by Rombuu (22914) on Tuesday December 21 1999, @05:47AM (#1456266) This book is available at Amazon for $20.97, instead of the $29.99 Fatbrain wants for it. If you are so into the whole patent thing, well go ahead and pay more I guess. I just saved 8 bucks, myself. Re:Where Extreme Programming Fails! by Woodie (Score:1) Tuesday December 21 1999, @05:52AMI'm with you! by DanaL (Score:2) Tuesday December 21 1999, @05:53AM"Understand the whole system" by seebs (Score:2) Tuesday December 21 1999, @06:00AMRe:Save some cash.... by the eric conspiracy (Score:1) Tuesday December 21 1999, @06:02AM where it fails (Score:3) by dutky (20510) on Tuesday December 21 1999, @06:02AM (#1456274) HomepageJournal I see a some big problems with the technique: no individual code ownership: this seems to suggest that the design would either be imposed from the top, which implies that coders would be treated as unspecialized labor, or that the entire team would be involved in the design of every piece of the code. Treating coders as unspecialized labor tends not to work because coders are not like factory workers but more like artisans or craftsmen. When you treat programmers like cattle they tend to resent it and deliver substandard code, at best. While getting the entire programming team involved with the design of every piece of the code might sound good, it results in design by committee, which doesn't tend to work in practice. The best designs come from inspired individuals or from very small teams of people. Finally, individual code ownership minimizes the need for communication accross the entire group (the N^2 communication problem noted by Brooks in The Mythical Man Month). By requiring a very high degreen of communication between all coders in the group, this technique is almost certain to fail for any group larger than a half dozen or so. new team members: the review asserts that "New programmers can also be brought in and up to speed much more quickly." but doesn't specify how. This is a similar problem to N^2 communication problem and was shown by Brooks to be one of the primary factors in killing large projects. The fact that the reviewer brushes this off so lightly, and that the table of contents doesn't show a chapter specifically dealing with it, suggests to me that it is not addressed. Ignoring N^2 communication issues is inexcusable in any methodology postdating The Mythical Man Month. debugging in pairs: debugging in pairs is a good idea, and should be used by any programming team that has the personnel to spare, however, it does not address the central problem of debugging. The problem with debugging is that it tends to take up a huge amount of the project time, and XP seems to want to add even more debugging to the mix (through the use of automated debugging tools). Just pairing your coders during debugging sessions won't reduce the total debugging time very much since it can't increase the number of cases covered or the range of debugging skills present by a significant amount. design to throw one away: The early release schedule seems to imply that the first coded design would be used as the production system. This is not a flaw solely in XP, but is rife in the current programming market. Many systems are built, essentailly, from the initial prototype, with no redesign. Brooks identified this as a problem back in the early seventies, but it doesn't seem to have made much difference to actual practice. A methodology that doesn't address the need to redesign the production system, however, will suffer from cost overruns and reliability problems (both of which XP is explicitly trying to avoid) due to the need to work around mistakes and compromises made when designing the prototype. unwarrented assumptions: the review seems full of unreasonable assumptions. Most programming projects don't have the latitude to set prices for each feature, or even to pick and choose which features to implement (at least not after the proposal has been made and the contract accepted). Even if you can set prices for individual features or components of the design, most features will not fall into the easy choice presented in the review. Any feature worth worrying about is likely to have effects across a large part of the design and leaving it out early one will pretty much exclude it later on as well. If XP is really dependant on some of these assumptions then it seems unlikely that it is a generally applicable methodology. So, it sounds a good piece, but I don't see anything that sets it apart from standard practice or from design methodologies that have already been elaborated elsewhere. Some of the ideas are good, but others just seem to be naieve or illconceived: some even seem to smack of outright voodoo software engineering. Re:It's not bad at all by A Big Gnu Thrush (Score:1) Tuesday December 21 1999, @06:03AMRe:Pair programming works!!! by oddjob (Score:1) Tuesday December 21 1999, @06:04AMRe:I'm with you! by adimarco (Score:2) Tuesday December 21 1999, @06:05AMRe:Also look at "The Pragmatic Programmer" book by fredb001 (Score:1) Tuesday December 21 1999, @06:07AMRe:Recipe for Disaster by the eric conspiracy (Score:2) Tuesday December 21 1999, @06:09AMRe:"Understand the whole system" by RobertEdwards (Score:1) Tuesday December 21 1999, @06:11AMRe:Save some cash.... by Anonymous Coward (Score:1) Tuesday December 21 1999, @06:12AMRe:Pair programming works!!! by pieguy (Score:1) Tuesday December 21 1999, @06:14AMAnother alternative by Esjion (Score:1) Tuesday December 21 1999, @06:14AMRe:Communication and Specification by richieb (Score:2) Tuesday December 21 1999, @06:14AMDebugging Party by Midnight Ryder (Score:2) Tuesday December 21 1999, @06:20AMcustomer rep sits on his ass by Anonymous Coward (Score:1) Tuesday December 21 1999, @06:23AMRe:Does this book seem to be pushing a BAD idea? by RobertEdwards (Score:1) Tuesday December 21 1999, @06:23AMGerald Weinberg: Psycology of Computer Programing by Anonymous Coward (Score:2) Tuesday December 21 1999, @06:32AMRe:customer rep sits on his ass by RobertEdwards (Score:1) Tuesday December 21 1999, @06:33AMExtreme Programming! by SydBarrett (Score:1) Tuesday December 21 1999, @06:37AMRe:Library Coding Tip by BeanThere (Score:1) Tuesday December 21 1999, @06:38AM[OFFTOPIC] Re:Moderator by El Volio (Score:1) Tuesday December 21 1999, @06:43AMRe:I much rather like sole systems by sjames (Score:2) Tuesday December 21 1999, @06:44AMRe:Extreme Programming web site by questor (Score:1) Tuesday December 21 1999, @06:46AMRe:Communication and Specification by panda (Score:1) Tuesday December 21 1999, @06:49AMRe:Recipe for Disaster by mayoff (Score:1) Tuesday December 21 1999, @06:50AM A personal experience... (Score:3) by William Tanksley (1752) on Tuesday December 21 1999, @07:03AM (#1456300) A foundational part of XP is the mutability of code: you write the code for what you know now, and be willing in the future to totally change it. One of the best technical books I've read recently discusses the how-tos of this: "Refactoring [bestbookbuys.com]" (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 [xprogramming.com] 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 Re:I much rather like sole systems by Phouk (Score:1) Tuesday December 21 1999, @07:05AMComparison shop (was: Save some cash....) by RocketJeff (Score:2) Tuesday December 21 1999, @07:10AMRe:... by staplin (Score:1) Tuesday December 21 1999, @07:13AMRe:Where Extreme Programming Fails! by William Tanksley (Score:2) Tuesday December 21 1999, @07:16AM Have the scoffers actually tried coding like this? (Score:3) by vivarin (106778) on Tuesday December 21 1999, @07:17AM (#1456306) Homepage 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. Re:Communication and Specification by mayoff (Score:1) Tuesday December 21 1999, @07:21AMRe:Today's Buzzword is... by William Tanksley (Score:2) Tuesday December 21 1999, @07:21AMRe:I much rather like sole systems by samantha (Score:2) Tuesday December 21 1999, @07:22AMRe:Comparison shop (was: Save some cash....) by William Tanksley (Score:2) Tuesday December 21 1999, @07:23AMNot in this case by Anonymous Coward (Score:1) Tuesday December 21 1999, @07:33AMXP works for me. by emeade (Score:1) Tuesday December 21 1999, @07:37AMRe:where it fails by mayoff (Score:1) Tuesday December 21 1999, @07:38AMMountain Lightning... by Svartalf (Score:1) Tuesday December 21 1999, @07:39AMRe:Communication and Specification by DanaL (Score:2) Tuesday December 21 1999, @07:43AMRe:Library Coding Tip by questor (Score:1) Tuesday December 21 1999, @07:44AMModerate this up please! by HarpMan (Score:1) Tuesday December 21 1999, @07:51AMRe:Where Extreme Programming Fails! by NateDawg (Score:1) Tuesday December 21 1999, @07:56AMRe:Communication and Specification by questor (Score:1) Tuesday December 21 1999, @07:56AMRe:What is the "engineering phase"? :) by Eric Green (Score:2) Tuesday December 21 1999, @07:58AMRe:I much rather like sole systems by wildcoder (Score:1) Tuesday December 21 1999, @08:01AMRe:I much rather like sole systems by pieguy (Score:1) Tuesday December 21 1999, @08:08AMRe:Where Extreme Programming Fails! by stephend (Score:1) Tuesday December 21 1999, @08:08AMRe:cost? by ranton (Score:1) Tuesday December 21 1999, @08:11AMRe:Library Coding Tip by BeanThere (Score:1) Tuesday December 21 1999, @08:12AMHow adverse to change are you? by GBSW (Score:1) Tuesday December 21 1999, @08:15AMRe:Extreme Programming! by WinTired (Score:1) Tuesday December 21 1999, @08:16AMRe:Moderator by questor (Score:1) Tuesday December 21 1999, @08:16AMDon't forget www.ExtremeProgramming.org by cpeterso (Score:2) Tuesday December 21 1999, @08:19AMRe:... by GBSW (Score:1) Tuesday December 21 1999, @08:19AMDesign Patterns by Corrinne Yu (Score:2) Tuesday December 21 1999, @08:22AMRe:cost? by richieb (Score:1) Tuesday December 21 1999, @08:22AMRespect for the author by smalltalker (Score:1) Tuesday December 21 1999, @08:26AMRe:Gerald Weinberg: Psycology of Computer Programi by BillWhite (Score:1) Tuesday December 21 1999, @08:31AMA Reason to like XXTreme PProgramming. by BillWhite (Score:2) Tuesday December 21 1999, @08:32AMRe:Planning is good! by johnburton (Score:1) Tuesday December 21 1999, @08:40AMRe:Recipe for Disaster by darkscanner (Score:1) Tuesday December 21 1999, @08:45AMI did this too; it worked great! by Anonymous Coward (Score:2) Tuesday December 21 1999, @08:46AMXP was designed for exactly that situation! by cpeterso (Score:2) Tuesday December 21 1999, @08:49AMRe:cost? by segmond (Score:1) Tuesday December 21 1999, @08:53AMRe:Today's Buzzword is... by homunq (Score:1) Tuesday December 21 1999, @09:02AMRe:Sounds Promising by psaltes (Score:1) Tuesday December 21 1999, @09:02AMRe:I much rather like sole systems by Captain Teflon (Score:1) Tuesday December 21 1999, @09:23AMPart time job by ranton (Score:1) Tuesday December 21 1999, @09:25AMRe:cost? by waveman (Score:2) Tuesday December 21 1999, @09:35AMThe Unit Test *IS* the SPEC and ReFactoring Wins by john@iastate.edu (Score:1) Tuesday December 21 1999, @09:55AMRe:Test-first seems good, but what about UI? by Zurk (Score:1) Tuesday December 21 1999, @10:00AMRe:Test-first seems good, but what about UI? by Lister of Smeg (Score:1) Tuesday December 21 1999, @10:10AMRe:Today's Buzzword is... by William Tanksley (Score:2) Tuesday December 21 1999, @10:11AMPink Floyd lyrics in the headers by lfd (Score:1) Tuesday December 21 1999, @10:14AMNo More Code Monkeys! by john@iastate.edu (Score:1) Tuesday December 21 1999, @10:26AMnot to get into an amazon.com flame-trap, but... by Misha (Score:1) Tuesday December 21 1999, @10:40AMRe:end user v. manager feedback by 10am-bedtime (Score:1) Tuesday December 21 1999, @10:42AMRe:Extreme Programming! by Gomez (Score:1) Tuesday December 21 1999, @10:58AMprogramming in pairs by ixo (Score:1) Tuesday December 21 1999, @11:35AMRe:cost? by DGregory (Score:1) Tuesday December 21 1999, @11:45AMRe:Recipe for Success by gstamp (Score:1) Tuesday December 21 1999, @12:08PMRe:Communication and Specification by jlowery (Score:1) Tuesday December 21 1999, @01:10PMACM Programming Contest by DMuse (Score:1) Tuesday December 21 1999, @01:16PMre: guys/girls/pair coding by chocolate pi (Score:1) Tuesday December 21 1999, @01:34PMwatch your scope run away by zzzeek (Score:2) Tuesday December 21 1999, @01:40PMRe:cost? by gstamp (Score:1) Tuesday December 21 1999, @01:51PMXP Is Engineering by PeterAtWebsense (Score:1) Tuesday December 21 1999, @02:06PMRe:Planning is good! by gstamp (Score:1) Tuesday December 21 1999, @02:07PMRe:I'm with you! by gstamp (Score:1) Tuesday December 21 1999, @02:55PMRe:business programming & Open Source by Pfhreakaz0id (Score:2) Tuesday December 21 1999, @03:01PMRe:Recipe for Disaster by the eric conspiracy (Score:2) Tuesday December 21 1999, @03:09PMRe:Does this book seem to be pushing a BAD idea? by alan_knight (Score:1) Tuesday December 21 1999, @03:26PMRe:Recipe for Disaster by RalphEJohnson (Score:1) Tuesday December 21 1999, @04:56PMXP Pain? by HalB (Score:1) Tuesday December 21 1999, @05:13PMRe:Save some cash.... by HalB (Score:1) Tuesday December 21 1999, @05:37PMRe:not to get into an amazon.com flame-trap, but.. by HalB (Score:1) Tuesday December 21 1999, @05:39PMRe:cost? by BinxBolling (Score:2) Tuesday December 21 1999, @07:27PMRe:Where Extreme Programming Fails! by denormaleyes (Score:1) Tuesday December 21 1999, @07:41PMRe:Recipe for Disaster by TimoT (Score:1) Tuesday December 21 1999, @08:50PMpractices that succeed by Lumpish Scholar (Score:2) Tuesday December 21 1999, @09:05PMRe:Trolling v.s. Flamebait. by rent (Score:1) Tuesday December 21 1999, @09:18PMRe:programming in pairs by BigTom (Score:1) Tuesday December 21 1999, @09:22PMsummary of XP by Lumpish Scholar (Score:2) Tuesday December 21 1999, @09:27PMRe:Recipe for Disaster by David Kennedy (Score:2) Tuesday December 21 1999, @10:42PMRe:I much rather like sole systems by Basje (Score:1) Wednesday December 22 1999, @01:37AMRe:watch your scope run away by gtstellf (Score:1) Wednesday December 22 1999, @05:11AMRe:It's not bad at all by greendot (Score:1) Wednesday December 22 1999, @06:39AMRe:Comparison shop (was: Save some cash....) by sparcE (Score:1) Wednesday December 22 1999, @08:30AMRe: Peer-review ... novel concept? by SamesShuster (Score:1) Wednesday December 22 1999, @08:39AMRe: Peer-review ... novel concept? by SamesShuster (Score:1) Wednesday December 22 1999, @08:43AMRe:Cheating by SamesShuster (Score:1) Wednesday December 22 1999, @09:07AMRe:Library Coding Tip by SamesShuster (Score:1) Wednesday December 22 1999, @09:36AMRe:Detailed Specification by SamesShuster (Score:1) Wednesday December 22 1999, @10:13AMRe:where it fails by SamesShuster (Score:1) Wednesday December 22 1999, @10:45AMRe:Recipe for Disaster by alan_knight (Score:1) Wednesday December 22 1999, @11:53AMRe:I much rather like sole systems by DonWells (Score:1) Thursday December 23 1999, @04:17AMRe:I much rather like sole systems by DonWells (Score:1) Thursday December 23 1999, @04:20AMRe:I much rather like sole systems by DonWells (Score:1) Thursday December 23 1999, @04:29AMRe:Extreme Programming not so extreme by DonWells (Score:1) Thursday December 23 1999, @04:48AMActually you reduce the cost. by DonWells (Score:1) Thursday December 23 1999, @04:53AMRe:Library Coding Tip by BeanThere (Score:1) Friday December 24 1999, @12:50AMRe:Task Difficulty by DonWells (Score:1) Friday December 24 1999, @07:50AMRe:Library Coding Tip by SamesShuster (Score:1) Friday December 24 1999, @08:57AMRe:where it fails by DonWells (Score:1) Friday December 24 1999, @09:28AMRe:Where Extreme Programming Fails! by DonWells (Score:1) Friday December 24 1999, @09:44AMRe:watch your scope run away by Martijn Meijering (Score:1) Saturday December 25 1999, @08:17AMRe:Where Extreme Programming Fails! by Martijn Meijering (Score:1) Saturday December 25 1999, @08:24AMRe:cost? by Martijn Meijering (Score:1) Saturday December 25 1999, @08:41AMRe:cost? by Martijn Meijering (Score:1) Saturday December 25 1999, @08:42AMRe:Communication and Specification by Martijn Meijering (Score:1) Saturday December 25 1999, @08:54AMRe:Communication and Specification by Martijn Meijering (Score:1) Saturday December 25 1999, @09:03AMRe:Planning is good! by Martijn Meijering (Score:1) Saturday December 25 1999, @09:16AMRe:Library Coding Tip by Martijn Meijering (Score:1) Sunday December 26 1999, @06:26AMRe:watch your scope run away by DonWells (Score:1) Sunday December 26 1999, @09:33AMRe:Design Patterns by veldrane (Score:1) Tuesday December 28 1999, @09:01AMRe:I much rather like sole systems by Cuthalion (Score:2) Wednesday December 29 1999, @07:20AM32 replies beneath your current threshold. (1) | 2 | 3 Search Those who don't know, talk. Those who don't talk, know. All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2008 SourceForge, Inc. home awards contribute story older articles sourceforge, inc. advertise about terms of service privacy faq rss pageTracker._trackPageview();  |
|
