I'm reading eXtreme .Net by Neil Roodyn. This is my first intro to Xtreme programming. I've downloaded NUnit and I'm playing with this.

Does anyone adhere to the extreme programming mentality?

Jeff

i personally cant stand it. MSF Agile is much more promising. Its like XP buts it has more structure and planning, but not overkill like the pure MSF. I think that MSF Agile combined with Test Driven Development is the way to go personally.

I like some things about XP. I'm just a lone dev though

Check out the first link in this blog post from Roy. http://weblogs.asp.net/rosherove/archive/2005/04/16/400987.aspx

I'm envious of that setup. Not that I couldn't do it. But, being the sole dev makes it not worthwhile I think.

XP rules. My current team has been doing it for years. We ship new features every three weeks.

--Bruce

My issues with xp are the lack of plannig from the start and often times you spend too much time refactoring where if you would just give a little though to what really needs to be done along with the architecture in advance, you could get the code right the first time.

maybe i am missing something about xp, after reading through "Extreme Programming Adventures in C#" and seeing what a debocle that book is, I could have a tainted view of XP.

Basically, no matter what software development cycle you follow, if you do the things listed below, youll win every time:

1. Listen to clients, product champions, and management when gathering artifacts
2. Keep goals, modules, and scope narrow
3. Build unit tests from requirments
4. Refactor as you go
5. Plan for change, leveraging hooks and OOD where practical to facilitate change
6. Force clients / management to be realistic about requirements, timelines, and resources
7. Use requirements in your test plans

Give clients & management something to see early on in the game so that they dont get discouraged and start wondering what you are up to.

I was browsing through the local book store today and ran across a decent book by APress called "Agile Development with ICONIX Process." Which IMO is a fairly realistic approach to the software development lifecycle.

At the same time, I ran across another book by the same authors and published by Apress as well, titled "Extreme Programming Refactored: The case against XP." In this particular book was a peice of sarcasm / satire that, IMO, has one of the funniest acronyms for XP. The acronym used was that basically XP was .... "DAFT CRAP." DAFT = Design After First Testing and CRAP = Constant Refactoring After Programming.

Sorry if some are offended, I just thought that it would make some people chuckle.

heh

XP has some good points, though the real 'ad-hoc' experience is a bit bad IMHO. When you mention that to agile advocates I always get the reply "Oh, but we DO design first!", hahaha yeah right

Good morning.

XP - Good or Bad? - According to me BAD! but with some nice ideas like NUnit testing and pair programming.

Well my team and i have been doing XP for about 8 months now.

Pro's Pair Programming (2 pair of eyes and brains) NUnit Testing

Cons Lack of planning To much refactoring due to lack of planning. Wasting time.

According to the rules of XP - you are not suppose to think about future developments. Only about the here and now. This causes you to have to redo alot of code - almost every 2nd week for us - due to change of requirements - Alot of these changes usually are seen while in the initail development phase but because they are not part of the current requirements we have to ignore it and continue.

wayne wrote:

Good morning.

XP - Good or Bad? - According to me BAD! but with some nice ideas like NUnit testing and pair programming.

Well my team and i have been doing XP for about 8 months now.

Pro's Pair Programming (2 pair of eyes and brains) NUnit Testing

I consider these as the pro's as well!

Cons Lack of planning To much refactoring due to lack of planning. Wasting time.

According to the rules of XP - you are not suppose to think about future developments. Only about the here and now. This causes you to have to redo alot of code - almost every 2nd week for us - due to change of requirements - Alot of these changes usually are seen while in the initail development phase but because they are not part of the current requirements we have to ignore it and continue.

This isn't all that bad, though. If you put aside the refactoring time loss, you can gain a lot of time by not over-engineering the system for future enhancements which might never come. If you take that into account, you've already won a lot of time.

Though, the time wasted through refactoring is IMHO a lot and shouldn't be ignored. Some people try to make you believe that by using a refactoring tool, you won't lose any time. Which is bogus of course, because renaming some names and wrapping some lines with some code isn't the real refactoring time you'll lose. The real time is lost by re-engineering pieces of code and I mean: LARGE pieces of code, which takes time and which could have been won if the research was better beforehand.