Extreme Programming
|
| ||||||||
 |
 |
|||||||
|
Extreme Programming |
||
|
Message Forum - Archive, Page 2 Message Index
Keep things in perspective re: Keep things in perspective Question to Ron re: Out of context Can XP work as an open-source project? Refactor Mercilessly XP deserves more credit A Nautical Analogy The Messages
Keep things in perspectiveI approached XP with a healthy dose of skepticism driven by my 10+ years developing software. What I found, though, was a set of not-new practices that made me a better programmer (previously thought to be inconceivable :-) ). Youīve got to know when XP (or any of the agile methods) are appropriate. If you are building "flight trajectory calculations for [a] missile targetting system," you shouldnīt even be thinking about XP or agile. For Godīs sake, get those requirements down, in stone, simulated, have the engineers look them over, and so forth. A mathematical simulation of airline industry economics (yawn) being specified by an economist who is still trying to work out the details of the analysis was a good target for XP. Obviously, you have well-founded reasons for why you (personally) should not use XP. Good for you. I guess I wonder why you care so much about how other people are building software. Iīm sorry, but Mattīs unfounded (as in no-research-to-back-it-up), cynical, and argumentative bad-mouthing of XP contributes nothing to a healthy debate of software practices. Do what works for you. When XP fervor eventually goes gently into that good night, many of the practices that XP promotes will linger simply as good ways to program. Jim Villani j.villani@computer.org Virginia, US Mon Dec 31 15:49:28 EST 2001 re: Out of context > Many of the quotes from the XP source materials > are taken out of context. Which ones? That isnīt a "posturing" question, I would seriously be interested to know. > Consider for instance > your own article The Case Against XP where you > state "I have... gone to dig ditches by the side > of a road somewhere." Did you really mean to say > that? Well done, youīve cunningly uncovered the articleīs hidden subtext :o) Matt England Mon Dec 31 16:01:09 EST 2001 re: Keep things in perspective > I approached XP with a healthy dose of > skepticism driven by my 10+ years developing > software. What I found, though, was a set of > not-new practices that made me a better > programmer (previously thought to be > inconceivable :-) ). I agree, XP does promote some good practices (as I mention in the articles). Iīm glad they improved your programming. And youīre right about the "missile targetting system" example not being entirely appropriate. Iīll improve that part of the article soon. Thanks for pointing that out. You wonder why I care so much about how other people are building software? Yes, your World would be a much better place if more people stayed silent about their beliefs. If you strongly believe a software practice to be flawed, how can you "bad-mouth" it without appearing to be cynical? The articles are based on real experience of what works and what doesnīt in software development, so your assertion that they are "unfounded" is itself unfounded. Just read the articles for what they are: one programmerīs opinion (as the first article clearly states at the beginning). Matt London, England Tue Jan 01 07:07:26 EST 2002 Question to Ron Ron wrote a while back: > The article on XPīs values is flat incorrect > in some of its characterizations, and > draws conclusions that are not borne > out in the many projects that are doing XP. Would you care to mention at least just a few of them, or even one, just to get the ball rolling? You see, at the moment, your responses to Matt are that he is wrong or misleading, but until you specify where he is wrong or misleading, and why. By refusing to even start going into detail, you seem to acknowledge that Matt is right, but for some reason dare not admit it. Les anon@nospam.please NB, Canada Fri Jan 04 11:15:34 EST 2002 re: Out of context You have pointed out a contradiction that is explained clearly at my web site provided you read the entire page and not just the quotes. The contradiction is in the idea that XP practices all support each other. They do. Used together they are much easier and work fairly well. However, you can use one or two to solve a specific problem that you might be encountering. But the catch is that it requires extra effort when applied that way. The good news is that most people are more than willing to put forth the extra effort to solve the biggest problem they have. But, adding practices piece meal is an up hill climb and it is easy to slide back down. I donīt find this to be a contradictory statement. The jig saw puzzle quote is taken from a page about traditional methods being largely monolithic while XP is comprised of practices. Doing only one practice would in most cases make no sense but is not necessarily a crazy idea. Unit testing on itīs own is not a crazy idea is it? But if that is all there is to a methodology it would make no sense. It is only when all the practices are present that a reasonable methodology emerges. "Together developers and customers move the cards around on a large table to create a set of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired." This is not intended to imply the entire system is delivered early. You are correct, that would be ridiculous. It is in the context of deciding which user stories to do next. Choosing a set of stories which will be of value to the customer should only a portion be released seems to be a good idea to me. Why not let the partially finished system be of use to someone? I have done this on several projects even pre-XP and believe me it is appreciated. From your web site "Your co-worker comes round and tells you your code must compile perfectly in five minutes, ready for integration." This is ridiculous of course. You must have misunderstood. Integration is when you are ready and is never forced, ever. This is fully explained on http://www.extremeprogramming.org/rules/sequential.html. I will make this more clear on the integrate often page. From your site "The example given here is amazing." That example is a toy example and an attempt to put on paper that which defies being put on paper. You know this. Letīs keep this above the belt, shall we? This is not to imply that some of your concerns are not valid. Negotiation of contracts, especially fixed cost are always problematic. XP does not change this, but XP does try to alleviate the problem some what by at least making a best effort to deliver a system that the customer actually wants and can actually use to solve the problem in question. I have been in the software industry a bit longer than you and have seen many systems delivered and never used because they implement the specification but do not solve the problem. Your criticism of on-site customer is well founded. There is a problem getting the right customer for the job full time. But shouldnīt we ask some more fundamental questions? How much is this application really worth? Is this really a candidate XP project? In many cases the project should not be attempted with XP because it is not valuable enough to warrant an on-site customer of appropriate experience level. It has been my experience that many customers who might seem to not know what they want actually do. They know exactly what problem must be solved. What they donīt know is how this god-awful computer technology could possibly help in any way! These customers are the most difficult, most common, and hardest to get clear specifications from. But they do know what they want, you just need to figure out what the correct questions to ask are. If you can figure that out up front then BRAVO! My experience has been that the best way to figure out what to ask is to do it in the concrete context of the system that has been built so far. There was a section in there about polluting the customer with technical details and I can not seem to find it just now. That seemed like a reasonable concern to me. Did you remove it? One does need to be aware of when a specification is made based on real need or a misconception of what is really possible. This is true of all projects. The difference here is that as you grow to know your customer on a face to face basis you can usually tell when he is just settling because of perceived technological constraints or is actually telling you the requirements are not that demanding. I like the quote from your site "Only amateurs try to come up with īfancyī moves" if only Rational would realize how true this is. If you meant to imply XP is a fancy move you might want to take that off the page. Everyone who has looked at the web site knows XP is many things, but not fancy. Don Wells Don Wells Michigan Sat Jan 05 17:45:16 EST 2002 Can XP work as an open-source project? I donīt think so. Iīve been working in an XP-like environment: - very close cooperation without being in actual pairs, - high rate of CVS checkin, - stand-up meetings, - refactoring as required (fully justified) - unit testing for core areas but not fully test-first (lotta GUI and the overhead is too much) most of all itīs a team environment focussed on the team meeting deadlines each week. I also have my own software company operating in a distributed manner and have been trying to achieve some of the same robust, high-productivity results. I canīt. I have come to the conclusion that major OpenSource projects that are seen as highly productive are probably productive in the sense of results but if you evaluated the total cost of person hours would not be optimal or even moderately efficient. I donīt think XP or other intensely-focussed Agile methods are possible in a distributed manner, unless there are some exotic support tools that "eliminate distance" (Andy chokes slightly on marketing-speak). Andy Dent dent@oofile.com.au Perth, Western Australia Mon Jan 28 14:16:04 EST 2002 Refactor Mercilessly Matt, In the Key Rules and Tenets section of your Case Against XP, Iīm not sure you have the right idea about XP and refactoring. Now, I donīt claim to be an XPer, and this may just be an example of a topic on which the XP literature contradicts itself, but I donīt think XP encourages over-optimization of code. In fact, quite the opposite. I remember in the XP Explained book, Beck gives the example of implementing something with a brute force method, then only optimizing it if necessary. Not that I think that approach is always appropriate, but the general mindset is good. In some cases, a software developer can rely on his experience with the performance of different algorithms to choose the one that is best. No point in choosing the easiest to write algorithm if you and your team-mates are >90% sure it wonīt be good enough. At any rate, I agree with what you are getting at: "Only optimize where optimization is necessary." Iīm just not sure that viewpoint is in opposition with XP. Jack Humphrey jack@fivewells.com Austin, Texas, USA Mon Feb 18 21:35:34 EST 2002 XM: Extreme Management I read a Cutter article the other day that said something like the following: > ... Often, these situations require radical > approaches. For example, it may be necessary > to tell the business that IT cannot meet all of > the commitments it has made, but it wants to > meet the top three or four. If -- and this can > be a big "if" -- the business will at least > identify its top three or four needs, then IT > must meet its commitments. As the first > commitments are met, the next most important > are addressed, and they too must be met. This > is the only way to build a record of success > that can anchor a better business-IT > relationship ... Interestingly, this is similar to the approach taken by XP in matching requirements to functionality over a fixed release cycle. This observation has lead me to a new idea that I am tossing around which I am calling "Extreme Management". XM Key Features: - "Extreme(ly) Testing": The patience of engineering staff is tested time and time again as clueless techno-philistine managers argue the toss over such business-critical issues as: - "Is my data interchange format XML?" - "You should be using Sybase tables as a persistent message store!" - "Thatīs easy - itīs just a matter of turning on replication." - "Messaging! Rubbish, whatīs wrong with FTP?" - "You Arenīt Going to Need It (YAGTNI-tm)": Strategy? What strategy? We donīt need no stinkinī strategy!" - "Continuous Reorganisation": Bored? Have a meeting? Better still, reorganise your team, group or even division! Itīs easy if you follow these 4 simple steps: Step 1: Create new, sexy acronyms for your team, group or division Step 2: Move people around, preferably between buildings and floors Step 3: Reduce available employee desk space, particularly for support and infrastructure staff (ie those with the most kit) Step 4: Watch that bonus figure climb! So, get an XM programme working in your team today! M@ NSW, Australia Thu Feb 21 23:42:00 EST 2002 XP deserves more credit You say: "...However, RUP is still light-years ahead of XP in terms of pragmatism and sheer common sense. The main advantage of RUP is that none of it is really new: it is all based on best practices that have been tried and proven in the field, many times over. (This is as opposed to XP which is also nothing new, but is based on unstable practices that used together prevent each other from toppling over)." So what you´re saying is that RUP represents stable (existing) practices whereas XP represents unstable (existing) practices. This is perhaps the key point! Is it always possible to use (or misuse) an existing practice? YES. Do some RUP projects fail? Some will. Do some RUP projects succeed? Some will. Do some XP projects fail? Some will. Do some XP projects succeed? Some will. I think that the entire point of using XP is to prove that these practices can be stable if done correctly. We must remember that any method or methodology can be done to any level, good bad or ugly. I firmly believe that XP (or RUP for that matter) can work if you: A) Give it a chance B) Really sincerely follow the intent of the method C) Understand the limitations of that method!!! (Maybe the most important.) The thing that impressed me so much about XP was the fact that the authors (like Kent Beck) not only talk about how the practices can work, but how they can fail as well. I think this is what is the real difference between RUP and XP. I read several of the RUP books and, if I remember correctly, there was nowehere near the emphasis placed on failure modes. Nowhere was there a warning like this: "Be careful how much documentation you produce because you can run the project out of time/money by doing it." In summary, I think XP deserves more credit than you gave it because I believe it can work. Think about doing the opposite of all the XP practices; would that have a chance in hell or working? * No planning * Big infrequent releases * No metaphor * Complex Design * No testing * No refactoring * Nobody helps anybody (no pair programming) * No collective ownership * Big infrequent intergration * Constant Overtime * Customer not available or unresponsive * No coding standards How many of us out there have been on projects like this? ;) Robert Brown bob.brown@stratech.com Jax, FL, USA Thu Mar 07 13:02:02 EST 2002 A Nautical Analogy Matt Stephensī XP article sounds like a guy on the bridge of an aircraft carrier who sees a sailboat whip past. He chortles to himself, "What an immature vessel. If one of its subsystems failed (hull, mainmast, sail, etc.) it would be utterly incapacitated. And I bet its captain isnīt even sure of where heīs going! OUR course is plotted to the nearest centimeter. He doesnīt even belong in the water." Perhaps what the author fails to realize is that a majority of developers have no clear process AT ALL, that is, theyīre trying to cross the bay without even a boat to carry them. I suppose Matt would suggest they paddle back to shore and wrap themselves in several thousand tons of steel before they try again. Glade Diviney gladed@bigfoot.com Oregon, USA Fri Mar 08 12:15:18 EST 2002 re: A Nautical Analogy Glade - the trouble with analogies is that they mean everything and nothing. For example, you remind me of a frog on a rollerskate - but Iīm not going to say why. Iīm not a big fan of "heavyweight", high-ceremony methodologies. However, itīs a mistake to think that RUP is necessarily heavyweight. In any project you just use the parts of RUP that you feel you need, i.e. it can be very lightweight. Itīs up to you. Iīm all in favour of the GOALS of agile methods - just not XPīs way of achieving them (why? - read the article). Too much process can get in the way, and you risk losing sight of your original goal. Matt London, England Sun Mar 10 15:06:01 EST 2002
<< 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.