Heya LLBLGen forum-members,

Just as the titles says: What is your view on this new hype called extreme programming? Bullshit or the path to heaven...

ps: http://www.extremeprogramming.org is a good site on what XP is

IMHO, it's an excuse for poor planning and sloppy effort. People who code without direction now have a name for it.

It reminds me of "Spiral Requirements Gathering" which means, code something, show it to the customer to see if it's right, go back and code some more, show the customer, and so on, until you spiral in on what the product should be. Absolute crap.

Now, if you'll excuse me, I have to consult my Day-timer to see what I'll be doing the for the next twelve minutes, all in precisely color-coded detail...

People who code without direction now have a name for it.

lol, thats funny.

Management at our co decided that this is the new hype way in which we have to work. We have been doing it for about 4 weeks only - so i guess my experince won't count for much.

In my limited experience XP takes longer to develop with. (2 programmers per pc - 1 coding 1 checking out and suggesting on what you do and then swapping every 2 hours or so. Team members swap every week in our dev dpt) The NUnit test cases take forever.

I prefer Rational Unified still, maybe i am a control freak . XP is almost like a controlled Ciaos enviroment. Nobody has a exact overview of the project and good design patterns are sometimes abandoned because it is not needed it the current situation. - and according to me that is bad.

BlueCell wrote:

Heya LLBLGen forum-members,

Just as the titles says: What is your view on this new hype called extreme programming? Bullshit or the path to heaven...

ps: http://www.extremeprogramming.org is a good site on what XP is

It used to be called 'Ad-hoc programming' or 'hacking', at least that's how I see it. That is: if you use it in its purest form.

Software engineering requires a plan, what you're going to do. XP in its purest form doesnt have a solid plan, just rought edges and people are not forced to think about what they're going to do and better: why, but they're start hammering out code till it does what the rough spec tells them to.

Now, XP has good things, and I feel that XP has brought some great things to software engineering that shouldn't be overlooked. In its purest form it's IMHO not useful, but the aspects which are useful are invaluable IMHO. These are:

• unit testing. XP brought unit testing because it is a key element of XP: unit testing makes sure your interfaces still do exactly that what they should even after you've completely reworked the implementation
• refactoring. Refactoring was already known for decades, but in XP it got a name and the proper tools to be successful. Remember: never refactor without unittests in place, this means: first write the test, check if it's ok, then refactor and test again.
• pair programming. Pair programming is very efficient, research has shown. I only know pair programming from the demoparties I went to and the demoscene in the early amiga-days when we were hammering code on a single amiga 500, but it turned out these sessions were much more productive than when you had to do it all alone.
• less focus on 'plan everything ahead'. This is good, at least when the 'less focus' doesn't mean: 'no focus'. Too many projects have a very large plan with every detail worked out in a technical document (not functional research, but technical research) and when the specs change during the project because the client wants something added/changed, the work done in these plans can be thrown away.
• more focus on what you need now than what you need in 1 year. With proper planning, you can still make your application extensible for future updates but you shouldn't go overboard with that effort, i.e.: if it takes 2 months to add an extensible framework for features which take 1 week to add, it's not efficient.

LLBLGen Pro was my first project I did without a detailed technical plan. That is: there was a solid functional plan, but no in-depth technical plan what to do in every detail (just a more roughly technical plan): a more flexible approach, with a little bit of both. I must say it turned out great: the code is still very flexible to change/add features to, but also hasn't had a long delay because the technical document had to be written first. Technical details were filled in when the features were planned to be implemented, which turned out to be a good flexible approach in this project.

A warning is in order: I did know what to avoid in the first place, so I didn't make mistakes like adding all database code in 1 assembly which would make extending it with additional drivers a pain (for example). This doesn't have to be the case in your situation .

Concluding: I wouldn't go for XP in its purest form. A functional research and roughly technical document is essential for a succesful project, IMHO. Still the benefits of XP should and could be included in every day software engineering.

Wow thnx swallace, wayne and frans! You really helped me here, confirming what I felt before. That is, that planning is good, but don't overdo it. And as frans said, the tools provided by XP (some which already excisted) could and should be used even when you're planning. I will look more into these tools and see if they fit into my development process.

I think the book itself was probably one of the worst books I have ever read.

I could see holes in the code and pick out problems the guy was going to have as was describing the code. I was basically refatoring his code as he was authoring it.

From a design standpoint, I prefer to use MSF. Which does get daunting, and very tedious and time consuming. So, I try and really break things up into very modular and iterative development life cycles. For example, after the majority of the higher level tech docs are done, and the DB Schema is laid out, I use LLBLGen to do some code gen, then use NUnit to work out some of the heavy/high risk proof of concept issues.

I have found that when it comes to dealing with management, especially non technical management, they just want to see something on a screen that works. They are really like clients. they have little understanding of what it takes under the covers to make things work right and well with each other.

So by using some formal planning up front, it helps me and the team prepare our state of mind and direction. It also gives us a chance to ponder the next steps / iterations of the product. Then we break down the initial plans into small units of work, and then do some mock ups, and everyone is happy. We ultimately refine the functionality in the mock ups to meet the requirements as they are refined and as we encounter holes in the design. We also do code reviews and practice the "refactor as you go" idealology.

I have also found that using an MSF like approach, the code/product typically comes out as designed with minimal errors.