Extreme Programming
|
| ||||||||
 |
 |
|||||||
|
Extreme Programming |
||
|
Message Forum The purpose of these XP articles is not to outrightly dismiss XP, but rather to highlight what we feel is wrong with the way that it sets out to achieve the Agile goals. Please feel free to share your views here. We're open to constructive criticism of the articles, and will gladly update them based on your feedback...
Message Index:
The Messages: Going round and round and getting nowhere eXtremely fast? Another look at incremental and iterative developmentThe Methods & Tools newsletter has just released in its archive section the article "Going round and round and getting nowhere eXtremely fast? Another look at incremental and iterative development". This article defines the different process available for software development projects and when and how to use them http://www.methodsandtools.com/archive/archive.php?id=14 editor Wed Nov 10 12:07:49 GMT 2004 Excellent site I enjoyed this very much as I have been waiting to see some sceptical analysis of XP for some time. I didn't know C3 was actually cancelled but I do remember reading about the Smalltalk system payroll run which took 40hrs... The problem with XP is the same as with any software development methodology. People have good ideas, but then wish to make a living out of turning them into a system. This, combined with what Wittgenstein called our 'craving for generality', leads people to think that the resulting prescriptions have some universal value. They don't. XP, and agile generally contain some very useful ideas which developers should be aware of. But let's leave the zealotry behind and think for ourselves a little. Over a 20 year career I have developed solutions for numerous corporates and public sector organisations in the UK. I used to read books about development methods like XP a lot but became less enthusiastic when I realised that the people who control and run the projects I work on haven't the faintest idea what you are talking about. They have no interest whatsoever in 'good' or 'great' software, only in something that appears to work and is delivered on time and roughly on budget. That's worth saying again. They don't actually care if its good or not. That is software reality. Chris Rae chrisrae@sharedmodel.com Leeds, UK Mon Jan 31 15:48:31 GMT 2005 Pair Programming Health and Safety Two of the principles of XP that interests me is that of pair programming and co-located teams. Having worked in I.T for over 15 years as a programmer of one sort or another (currently ASP.NET). I'd always considered it a rather solitary occupation. I've since come across studies (by IBM I think!) that seem to suggest that office size has a big effect on productivity with one or two person offices being the optimim organisation (I think IBM have published figures on this.) The XP tenants of co-located teams and constant pairing would seem not to be the optimum way of organising development teams, especially large ones. It also occurs to me that, at least in Europe, that having two people use the same monitor might possibly run contrary to European Health and Safety legislation in most companies offices. This would leave Employers who insist that their employees pair program, open to prosecution. In my current organisation, who are extremely legislation aware, workstations are set up precisely for only one person. I have found that occasional pairing is very useful in solving tough coding bugs or design issues, not least because trying to explain your own work to someone else helps you to understand it yourself. I wonder if anyone has had any direct experience of these issues or perhaps has contrary evidence on how environmental factors affect programmer productivity. Mike Dunn dunnmikenospam602@hotmail.com London, England Thu Mar 03 13:29:25 GMT 2005 xp is blend of old truisms and new nonsense 0. Great site. 1. Value of simplicity and refactoring is old-school Unix - google Art of Unix Programming to learn the real theory. 2. Collective code ownership and pair programming only work when there are few developers and they are equally brilliant and have the same technical vision. Aside from that rare case, it's a prescription for anger and frustration (particularly when weaker team members find themselves unable to contribute anything since their pair always knows a better way). In my experience, collective code ownership appeals to guys who want to subvert the dev manager's authority. 3. Test driven design is an oxymoron. Knowing that a test passes presumes you understand the requirement. This canard is popular because it discounts the really hard and valuable work: designing the software. 4. Beck *is* right that you don't know the requirements in many cases until you build something (see Fred Brooks Myth Man Month 1975). But the answer is not to let a hundred jr developers wing it. The answer is to get a good guy (like Beck) and put him in charge of architecture. Unfortunately, XP won't allow this because it's based on the oh-so popular premise that all programmers are created equal - a premise, by the way, that is disasterously wrong. tom murphy tommurphyusa@yahoo.com detroit, usa Thu Mar 24 20:46:50 GMT 2005 Discuss the differences between eXtreme Programming and RAD. How are design specifications captured in both methods? plz provide me feedback......thanks Mahmood Khan mhk_room@hotmail.com Kuala Lumpur, Malaysia Wed Apr 13 07:31:51 BST 2005 XP, intelligence, honesty and pride Sorry guys this is a bit of an essay, but go with it anyway... I was considering the difference between evolutionary dvelopment and development by (up-front) design. Religious folks believe that the world was designed, but no-one can dispute that it has been shown that evolution *can* occur, and can give rise to complex (and functional) systems. So evolution creates solutions to problems (ie it solves problems) without the need for intelligent intervention. Design on the other hand requires intervention. Human beings evolved to be intelligent, and we tend to do a lot of designing in order to create solutions to problems. Why, when evolution can do this already? I believe it is because designing is simply faster. You get there sooner when you involve intelligence and do the steps of design, by comparison to evolution. Therefore we have two different tools for two different situations: evolution for when there's no intelligence available and design for when there is. This suggests that perhaps XP is for non-intelligent teams. However, I can't quite accept such a conclusion - XP teams in practice *do* contain intelligent people, and indeed the lower productivity of XP vs traditional methods isn't as marked as the difference between evolution and design. So we have two quandries: Why are intellignet people choosing a method that appears not to require intelligence, and why is it not as disasterously slow as real, natural, evolution? I theorise as follows: Intelligent people are still people and they have hangups like people do. This means that people may do things for reasons that they are not willing to admit. For example they may choose the XP process for some reason other than XP's main capability, that of creating results in the absence of intelligence. Suppose for example you are in a software management role when you are really an entrepreneur. Your job is to take a requirements spec and arrange for it to be implemented, when really you want to be writing that spec. Choose XP and the spec goes away! All you have to do is take the on-site-customer role for yourself, and you can guide the iterative design process so that it ends up implementing the system you wanted to create all along. The interesting part of the above paragraph is the last part about "the system you wanted to create all along" - a person who does this has secretly being doing an up-front design! Another example is a programmer who hates having to interact with executives and other corporate people who specify requirements. By choosing XP, it is possible to restrict such interaction to the absolute minimum of doing what it says on a task card. The actual code that results is often considerably more "joined-up" and structurally coherant than you would expect from doing a task at a time, but this must mean that the programmer has "second-guessed" the contents of the cards in order to figure out what is really required. Both examples involve the following factors: the use of duplicity to ensure that personal goals are satisfied, and the use of intelligent design to ensure that the project moves more swiftly toward a satisfactory conclusion than if a purely evolutionary approach had been applied. But there are problems. In the first example, others begin to suspect that there is a "hidden adjenda" (in the form of the unwritten up-front design) but cannot find out what it is, who creates it or how to influence it. In the second example, managers know there is a communication problem going on, but cannot get to the bottom of it. In both examples, the worst case is that the duplicity backfires and the individuals, together with their intelligence, end up in an unsustainable position and leave. It is a sad fact of life that pride and dishonesty often go hand-in-hand: people are proud of their ability to mislead, and they mislead about the sources of their pride. The fix for XP (if one exists) lies in breaking the chain of: intelligence -> dishonesy -> pride and replacing it with intelligence -> pride (which may be annoying but is actually harmess). If I am right, then the evolutionary (and hence intelligence-free) aspect of XP is it's biggest problem, and is the thing that must be removed with utmost urgency. John John Graley john.graley@ntlworld.com Cambridge, UK Sat Jun 04 20:02:15 BST 2005 The rise of the cottage industry With 25 yrs in software engineering and at several stages having more than a passing interest in software maturity and professionalism in delivering mission critical systems, I am averse to RAD, XP and other pseudo methodologies. However from a process perspective these methodologies are valid for some contemporary corporate needs and problem domains ie an environment where functionality and time to market counts. These methodologies are a result of the commoditisation of IT knowledge and tools, which is a good thing. However, this has several implications for professionalism in the software industry: - The professionalism learnt over centuries in other engineering disciplines is discarded as anyone can be contracted to build your bridge across the water and even change your mind halfway across. - Software development is now a cottage industry. - Software applications themselves are becoming commoditised (ie SAP, Oracle, Microsoft etc), leaving professional development to the application vendors. CFV clac6@hotmail.com Sydney, Australia Wed Jun 15 06:05:55 BST 2005 XP doesn't mean leaving your brain at the hat check Your review of XP is quite interesting, and I complement you on pointing out the weakest points. Clearly the largest impediment to people successfully executing XP is that they think they are doing XP when, in fact, they are doing something else. People ARE inherently lazy, and doing all of XP right is a very high focus activity. In some sense, you've given the impression that when you begin an XP project, you don't know if you are writing a word processor or software for the Space Shuttle. I don't think that's entirely fair. I think that a vague idea of what you want is always there when you begin. The problem is that the vagueness manifests itself differently in the minds of the programmers, and the minds of the customers. The purpose of design is to make sure that both parties have the same vague idea. This can and does happen with XP projects. The design game concept comes to mind. As an experienced programmer, I don't think you use XP as an excuse to write crap, which you know you will throw away later. Since we are lazy, we TRY to do it right the first time. We just recognize that it isn't always going to turn out as we hoped. It takes a pretty cynical person to suggest that a programmer would use XP as an EXCUSE to write poor code. -Kelly Kelly Anderson kelly@acoin.com Utah, USA Thu Aug 04 23:56:53 BST 2005 XP and Communism I'm new to XP. I joined a small "agile" shop that is proud of their talented, XP savvy programmers. When I first started I thought this was all interesting, but the more I read (they have a shelf stuffed with books on XP) the more I problems I found with XP, and then I found this site. I wanted to throw in another analogy, that's based on my conclusion that XP requires equally talented programmers for it to work (I don't mean talented, but equally talented, same as equally mediocre)... Is XP analogous to communism? The books sounds great, but in practice it falls on it's face a few years later. emi Detroit, MI, USA Fri Nov 04 19:41:53 GMT 2005 Is that a chip I see on your shoulder? I've been involved a little bit in ID debates and I get exactly the same feeling here as I do reading creationist dogma. Just because XP can be done badly doesn't mean it's a bad practice. Modern cars are pretty well engineered but you can still crash into a wall if you don't know how to drive them or simply aren't prepared to learn. These kinds of sites tend to preach to a willing audience but just in case anyone chances by who's trying to learn something about programming, be careful: pick your gurus wisely. noel darlow Scotland Sun Jan 08 08:33:07 GMT 2006 XP, Going Live and the Art Of System Maintenance First of all I must say I have never worked on an XP project, but it is something I have been interested in for a number of years. One area that really doesn't seem to be covered in the various XP books I have read is how a system goes live and how it will be supported. Yes there is lip service paid to 'productionizing' of the release, but how is a support team meant to maintain / enhance a system, which does not have an operational manual, detailed design notes etc., etc.? Whenever I read about XP it seems to treat development as an isolated process (and yes it does appeal to my geeky side). I have also been in the unfortunate position of picking up a system, where the original dev team has left and there is scant documentation. Are we meant to just continue refactoring ad infinitum? Comments welcomed Tim Riley riley_tim@yahoo.com Wellington, New Zealand Sun Feb 19 23:37:08 GMT 2006 XP... Hmm The more I read about XP, the more nervous it makes me feel. After having been a QA programmer for 10 years, I feel like I've got a pretty good grasp of both the world of developers (who often tend to assume that everyone else is stupid) and customers internal and external (who often loathe the arrogance of the dev. set, while simultaneously paying homage). Most devs I've known have *almost unanimously* hated design phases. They all itch to just "get started." Most project managers I've known have *almost unanimously* loved design phases as, frankly, that seems to be their primary reason for existence, except as a glorified gopher between the devs and the customer. A strong QA department falls somewhere in the middle. A strong QA employee knows the importance of keeping the project moving, but he also knows the criticality of keeping the project moving *in the right direction*. One of the fatal flaws of the "XP uber alles" mindset is that it all but does away with rigorous documentation, and it pretty much kills off QA. Of course there's personal bias in this, but I think that objective examination should reveal the problems with this. Developers are *trained to write code*. Yes, any developer worth his salt should also strive to write good code, but quality is not their number one focus. Customers, on the other hand, don't really care about the code, but they *want it to work* and (here's the catch) don't want bugs. You may be able to make a quick sale with a flashy project that you complete in record time today, but if it's got significant bugs, you won't do any repeat business. "But test-driven development solves all quality problems!" This is probably the most ludicrous claim I've ever heard about XP; how can a unit test find any bugs except *the ones it was designed to catch*? In other words, it's a domain problem: unit testing is important, but it is too narrowly focused to catch most integration issues, let alone focus on issues like "is this really the best solution? Is this really what the customer wants? Will this be stable?" You can argue that you can *write* tests that answer those questions (although some are in fact not automatable -- yet more reason for advocating a strong independant QA shop!) but the fact is that developers *simply aren't trained to think that way*. While a handful of the better developers may know what, say, a test equivalence class is, most won't, and so their tests, simply put, will be of crappy quality. This is the fatal flaw I see in XP: it eliminates any kind of rigorous quality control; from the specification phase (where all the big quality issues are initially caught) to the testing phase (which relies upon customers and developers, both historically horrible at catching the big bugs) quality is marginalized and treated as at best unnecessary and at worst a release-blocker. So I'd sum up by echoing an earlier poster: the best people don't get (software) religion. The best developers/QA/PM's/etc. develop a "toolbox" of possibilities, and *do what's best*. And here, again, is where hardcore XP falls down: this requires experience. There's simply no substitute for experience and domain knowledge -- there's no magic formula or set of rules that will make everything rip-roaring fast while preserving quality and best-customer-fit. You just have to have experience. Tom C Seattle, WA, USA Fri Mar 10 00:49:19 GMT 2006 Oh yeah (Can't seem to edit posts) I wanted to reiterate that my last post shouldn't be read as "XP sucks." It doesn't. There are many useful ideas that I've read in the various XP manifestos. If nothing else, all the recent (<10 years) furor in software design methodologies that RAD/XP/etc. have produced has stimulated a lot of thought-provoking debate, which can only lead to a stronger software development community in the long run. What I was criticizing was a mindless adherence to XP without understanding its rather significant drawbacks. The much-maligned "waterfall" model still has a lot going for it, and quite often the "best" methodologies is more reminiscent of a buffet than a grand, pre-planned banquet. You pick and choose the things that work best, and leave the rest. So -- I'm not bashing XP. I'm just bashing dogmatic adherence to XP as the "one true solution" to software development. There is no one best solution for all software development projects. Tom C Seattle, WA Fri Mar 10 00:53:37 GMT 2006 Real life "Dilbert" Oh, man! Now that I know what XP REALLY is, I think I'll run like hell in the other direction! If my last boss found out that you had just thrown away a days worth of coding (i was just a tech at this time), your head would be rolling! (think the Tony Soprano school of management!) Yes, of course sometimes it happens, but as a part of the "plan"? Now that I'm back in school going for my cs degree, I am VERY afraid of getting into an XP type department after reading this site. And I'm just a student!! This is what I thought the UML was like, just a way for a manager to "snow" the upper-suits with fancy diagrams. I wouldn't even do a cs lab project this way! (hell, it would never get turned in!!) Yes, it would be nice to have the ideas flow so one didn't have to think about the design phase. But this is the real world! I know this, because I'm now studying design after learning the syntax. The XP idea sounds fine for small projects, but anything larger and it sounds more like a future train wreck. No thanks, I'll proudly be "old school"!! chris meyer OR, usa Thu Sep 14 03:05:37 BST 2006 The engineering in software engineering The problem with XP is its "eXtremity". Ideas that are good in moderation are not always better when taken to an extreme. Just because your spaghetti sauce tastes better with a tablespoon of oregano doesn't mean you should add a pound of it. Good practice for most projects lies somewhere in between the extremes, and it still takes skill and experience to find where. My training is in both computer science and "classical" engineering. The latter has well-established methods and formalisms for dealing with uncertainty and change during a development cycle. And from the classical engineering point of view, some serious problems with XP are immediately apparent. The "all-or-nothing" interdependence of XP practices is a hallmark of a process that is non-linear, tightly coupled, and therefore quite risky. A system in which all the components must work perfectly or the entire system fails is sheer folly where avoidable. Good processes degrade well when implemented imperfectly and are meant to compensate for human weakness, not crumble under it. A moderate approach can, for example, mitigate inadequate testing with strength in paper design that makes it more likely the code was written right in the first place. Calling XP a "highly disciplined" approach isn't an adequate excuse for its brittleness or an absolution for the sins of its designers and evangelists. Another questionable XP premise is the value of unit testing in assuring overall correctness. Most errors in software derive from the interoperation of components and are not discoverable through unit testing. Believing that system correctness can be ascertained through inference by measuring unit correctness is as wrong-headed as saying that a building's sturdiness can be assured by a careful inspection of each individual brick before it's mortared in place. Flimsy buildings can still be made from good bricks if the bricks aren't placed according to a well-considered plan. Additionally, testing alone merely informs us that code DOES work; it doesn't necessarily reveal WHY code works, which causes problems down the road when you need to figure out why it DOESN'T work. I've seen software pass unit testing for years only to fail spectacularly when the thread timing was changed and exposed massive errors in concurrency control. I've seen reciprocal combinations of off-by-one errors go unnoticed for years because they conspired to pass the test suite, until one of them finally needed to be fixed and the whole conspiracy unraveled. Up-front design alleviates these kinds of problems, while extreme agility instead multiplies them by ignoring the reality of interaction. I firmly maintain that an engineer cannot devise tests that fully measure the strength of his own creation. An engineer always tests in ways congruent to his design. If someone else's discovery of a defect in an engineer's work is to be avoided for fear of "humiliating" the engineer, then the engineer has too much emotion invested in his creation to be a good steward of it. I don't have any qualms with XP's stated values. I have a problem with those values being taken to the extreme. Any engineering project involves inherently conflicting goals and inherently conflicting constraints. No "natural" solution to them exists; some form of compromise will always be needed. Engineering in its purest essence is the satisficing of those conflicts and cannot be successful in any "extreme" approach. I'm immensely proud to be part of the "old guard". I have seen and weathered a number of johnny-come-lately fads in software engineering, only to welcome the inexorable return to a time-tested moderate approach that consistently provides appropriate combinations of correctness, profit, maintainability, and flexibility for each project. Jay Windley jwindley@xmission.com Utah, United States Wed Nov 08 07:16:11 GMT 2006 XP Works I have read a couple of posts here and all of you ladies/gents are correct in a way. I just want to point out http://www.epoc.us they have a very new different aproach. I have tested it and it realy works, for multiple developers and single developers. Greetings from Telaviv Canan Erdol ISRAEL Wed Nov 22 09:55:40 GMT 2006 Around and Around Every time I start to write a critique on XP I read another article on the subject and realise that mine needs yet more refactoring to address the topic. It seems interesting (to me at least) to address why this should be so. I think it is because so much is written from a specific and narrow, even personal, standpoint. Abstraction is a technique which can (should) be applied to most discussions and topics. If you do you can remove the personal aspects. So, cutting to the chase, various parts of XP are good for various types of project. What are the constituents of projects that define their "types"? Well, technical nature, distribution, experience of staff, and so on, all affect the "type". Unfortunatly we do not appear to have an accepted set of project types, so we often end up personalising the debate and hence we get valueless discussions. I really do miss the academic analysis which we used to get ... presumably before real money got involved. Now, TDD, Test Driven Development, is a great technique and certainly better than what passes for testing in many shops. A less-quoted but famous Computer Scientis, Dijkstra once saiod that "testing can show the presence of bugs but not their absence". His point being that designing bugs out is a better way forward than detecting those already inserted. How does TDD deal with Dijkstra's statement? To my knowledge, it ignores it. Pair-wise programming is a similarly useful technique and has been used for many years. Once again, naming the technique is a useful service to us all ( I hesitate to call it a "Pattern") and it is good to be reminded of it. It of course can be used anywhere and anyhow, when it can provide benefit. In mature development shops where discussion and selection of appropriate process was always part of the job, Xp, Agile, etc represent little that is new. What they have (usefully) done is provide a label for selected techniques. Sadly they have not gone far enough with this abstraction and have been adversely affected by "fundamentalism", with such nonsense as "if you do not use all the techniques then ....". Perhaps the possible loss of consultancy explains the exaggerated defense of these methods. At best these processes provide a shopping list of techniques from which PMs and teams can select. At worst they are a cover for ill-disciplined developers. The truth of course is in between. George Brooke george@oaklodgeconsulting.co.uk Cambridge, UK Wed Feb 27 13:35:28 GMT 2008 6. Detailed specifications in XP are not created or preserved ....what is does mean? anyone please explain to me bout this word "Detailed specifications in XP are not created or preserved " ayu noridayuothman@gmail.com johor, malaysia Mon Jul 28 12:02:37 BST 2008 darry RukTN5 fvdf87y978sdct9bvd892hbsc darry smilis@hotmail.com TttuSPADyA, CmfnRTJSgGBOurZDAT Mon Aug 25 22:16:04 BST 2008 McxiRNBpEnMPxklHoc DAESH ONOTOLE V PRAVITELI VSELENNOI! GoogleBot gooblebot2311i@gmail.com RNEXgVMOL, tVqrbXliLeS Tue Nov 11 15:43:09 GMT 2008 KaPSPqLosXuh Not bad... Not bad. HairyMan mysuperhaerr@gmail.com wBWwtvpPa, WaTWDUtxAOVIeraiowK Wed Nov 12 03:55:48 GMT 2008 fVykeAtHZBLXyHu 4_2forpost.txt;10;15 yrtdDypIciorVqDebq jzJURBeXFOrlgMuOVD oNUMXSCMCHSeuet, wejhxDGaQmuTNsAh Wed Dec 03 10:58:57 GMT 2008 uoegvhEeBtfNnTp Thanks!, Jihmzgmu gskkqhvx@zniqlgrv.com vMwloeTl, BsJNFeFff Sat Dec 13 18:30:07 GMT 2008 Design without creation From the article: "You don't have to create something to know whether it is going to work or not." Really?!! I guess the entire world of researchers that build prototypes to demonstrate the viability of their ideas are just wasting money. If they're any good at their jobs they should be able to just put a design to paper and have it work, right? How dare a mechanical engineering group actually construct their new high-efficiency transmission. Don't they have confidence in their math? :P Milo Hyson California, USA Sat Feb 14 09:08:34 GMT 2009 qYYJAiVIHWpaxVVGaod njbjhbkvhggiygig9yyh nbmnbmnbnij hfkdskfkdjshfkhdks hfkdskfk@djshfkhdks.com owqnskKkCYY, kANporaWyoLQvDCzIwK Thu Feb 26 15:25:04 GMT 2009 mtntzqNtovv njbjhbkvhggiygig9yyh nbmnbmnbnij hfkdskfkdjshfkhdks hfkdskfk@djshfkhdks.com ZiAWvKbGKPoEKjBLBE, knRPpTwxZ Thu Feb 26 15:25:05 GMT 2009 XP low on re-use One of the big issues I have with XP is how short sighted the developers can become (or already are?) in an XP environment, Typically XP propagates, refactoring which is another name for bandages.Lets get it working for now and forget about re-usability for later. This is short sighted because it makes developers live in a silo, where they don't or are not able to think outside the box and develop for what might be in the future. A normal argument is; well in that span of time, all technologies will change. Good, granted that this will happen, or will it? The technologies might change, but there are things like common methodologies etc, that never change. Can you try using XP in OS development? try doing that and you have a crappy product. Re-usability is the most and should be the most important factor in writing code, because after all we are doing OO programming arent we? Anirudh Vyas USA Mon Mar 09 04:03:31 GMT 2009 Earlier Messages:
<< Back to the Latest XP Forum Messages |
||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.