Some time before, the term conventional method referred to the water fall model and all others like Spiral, Iterative development, RAD were considered to be new concepts. Now every where people are talking about XP (Extreme Programming). I have gone through the concepts of Extreme Programming. I am not that impressed. It is almost like Rapid Application Development Model with some changes like pair programming. Since there is no/very less documentation chances for reusability reduces. Only the person who developed a thing will own the knowledge, not the organization.
What are your views on Extreme Programming?. How far will it be suitable for software development?.
Originally posted by S.L.Narayanan: What are your views on Extreme Programming?. How far will it be suitable for software development?.
We like some of the methods that Extreme Programming espouses, but we feel like (as the back of our book says) XP as a whole is a little too... extreme. We recommend that instead of slavishly following any programming methodology, you pick and choose the techniques that work for your shop, and forget the rest. Take pair programming, for example. Give it a try in for a few weeks; if it works, great! If it's driving everybody crazy, give it up and try something else.
[ August 03, 2005: Message edited by: Will Gwaltney ] [ August 03, 2005: Message edited by: Will Gwaltney ]
Check out Ship It! A Practical Guide to Shipping Software<br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
Since there is no/very less documentation chances for reusability reduces. Only the person who developed a thing will own the knowledge, not the organization.
Actually, this isn't true for several reasons. First, in XP there is documentation, it's just that it's very effective documentation. Much of the documentation is in the code, which is often the best place for it, although XPers will also create external documentation as needed. They basically follow the practice Single Source Information.
Second, XPers focus on high quality, in practice significantly higher than traditionalists. They test first, ensuring that their code works, and they refactor to keep the design of high quality. They also follow coding standards. In practice this results in very high quality code, and as the reusability folks will tell you, the higher the quality the greater the chance that it's reusable.
Third, the organization owns all of the artifacts produced by the team. If they require documentation, and they often do, XPers merely consider this another requirement to be estimated and prioritized. So, if an organization is afraid of losing the knowledge, and thinks that writing documentation will help preserve it (a naive assumption at best), then they should choose to make it a requirement for the team. The only difference is that agile developers make the cost of documentation explicit to their stakeholders and then ask the stakeholders whether they wish to invest in the documentation. Interestingly, most stakeholders choose to reduce their investment in documentation and increase their investment in working software. You might find Agile Documentation to be of interest.
To add to what Scott said, much of the documentation that you need for reuse is provided by the unit tests. And another big part of knowledge transfer happens by Pair Programming, of course. In fact, in the context of Pair Programming (and XP's Collective Ownership), it doesn't make much sense to speak of "the developer" who developed some code.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
Originally posted by Will Gwaltney: but we feel like (as the back of our book says) XP as a whole is a little too... extreme.
Too extreme in which ways?
We recommend that instead of slavishly following any programming methodology, you pick and choose the techniques that work for your shop, and forget the rest.
Well, yes - I don't know any XP who would propose to follow it "slavishly". In fact, adapting it to your own environment is an important part of "doing XP".
On the other hand, the XP practices *do* work hand in hand in ways that are hard to understand if you didn't experience it. (Again, I think something similar is true for other processes.) So trying "full XP" for some time before adapting it *has* some merits...
Joined: Apr 01, 2005
Wow! I posted the query to one author and got back the replies from three. Great to see people like u explaining me.
Scott, yeah. What you have told is correct but as Will Gwaltney told, it is very tough to implement all the concepts of XP as a whole. So, better I will try to give it a try in a pilot when ever feasible and find out its advantages.