Extreme programming?

[GnuVince]

I'm not sure I understand what Extreme Programming (XP) is about. From what I read, it's about making tests before or as you write your program, and making sure each part of a program works as expected under all circumstances; is that it?

Also, are some languages better suited for XP?

[Strike]

http://www.extremeprogramming.org/what.html

:)

Really it explains it better than I could.

[kmj]

What strike said. For those who are too lazy to click the link; it's definitely about more than just what GnuVince said.

[jemfinch]

About test-first programming: I simply haven't found a use for it. Experiences differ, of course, and I'd likely find much more use of it if I didn't prefer to program in strictly-typed languages (and write in dynamically-typed languages as if they were strictly-typed languages), but my experience has been that it's not useful for me.

I don't know enough about the rest of XP to really say whether or not it's useful for me.

Jeremy

[GnuVince]

jemfinch: that's a thing I was thinking about. "If I write a project in O'Caml (or any other strictly typed language), and make sure all exceptions that could raise are caught, are there any bugs that can appear in my program, besides logic bugs?"

I mean, if I wrote a program in Ruby or Python, I'd need to do extensive tests with different types and see if the program acts correctly. But type errors just cannot happen in strictly typed language, right? So this means that you take a big bunch of tests and put them aside.

But I'm quite interested in their methodology nonetheless, I'm sure I could somehow benefit from it.

[sans-hubris]

Summary, XP is really about how people should program in groups, when they're all in the same location. Or something like that. That's what I was told anyway. That's probably only part of the picture.

Anyway, I'm trying to imagine "Extreme Programming" competition, you know, like those "Extreme" sports games? Can you imagine the announcer: "OMG! He just did an inverted for loop with a nose-grind integer!"

Now that I read a little more on it, it seems to encompass many of the software development principles used by much of the open-source community, which seems to make sense. The only difference is that XP is adapted for commercial purposes.

[GnuVince]

sans: hehe! Yeah!

"GnuVince is sponsored in part by O'Caml: when you don't want type errors! And by INTERCAL, for those of us who want to be rejected!"

[sans-hubris]

"That was a pretty good coding session there for ndogg, especially with a score of 86.5. It may not sound like a lot right now folks, but it's only the first round. ndogg told us in an interview earlier that for the next round he'll be going for a 360 chair swirl with a while loop ollie. If that's not exciting, I'm not sure what is!"

[kmj]

Originally posted by GnuVince
jemfinch: that's a thing I was thinking about. "If I write a project in O'Caml (or any other strictly typed language), and make sure all exceptions that could raise are caught, are there any bugs that can appear in my program, besides logic bugs?"

I mean, if I wrote a program in Ruby or Python, I'd need to do extensive tests with different types and see if the program acts correctly. But type errors just cannot happen in strictly typed language, right? So this means that you take a big bunch of tests and put them aside.

But I'm quite interested in their methodology nonetheless, I'm sure I could somehow benefit from it.

Of course, semantic bugs are the worst kind. Two people at one desk will greatly reduce semantic bugs, and most likely decreases time to debug by significantly more than twofold. I work with a couple guys who work as a team.. they've never read up on XP, but they'e been working as a team for years and years now. They speak very highly of it.

[stuka]

jemfinch: the point of the Test First Design is not to catch type errors (though if you are coding in Ruby or Python, it would), but rather to catch the logic (semantic) errors. By writing tests which exercise your code, and cover any possible input scenarios, you can verify that you haven't omitted some condition, or interpreted one incorrectly. One way to think of the tests is to consider them assert()s written outside your code, so you don't have to deal with removing them later. The tools that exist (JUnit and its derivatives in the OS world) provide a method for executing a test suite in an automated fashion, helping to provide thorough test coverage. Obviously the size of a program will influence how useful this method is - I'm sure most of your programs are (comparatively) small, so the benefits of TFD will be minimal for you - for larger projects, they can be indispensable.

[jemfinch]

Originally posted by Stuka
I'm sure most of your programs are (comparatively) small, so the benefits of TFD will be minimal for you - for larger projects, they can be indispensable.

Actually, a lot of my programs are probably large enough to provide adequate test-sites for TFD (e.g., my O'Caml bot v1 was ~20,000 lines of code; my second version was about 10,000 lines of code; SupyBot is ~8,000 lines of code). They're not huge (nor maybe even big), but they're certainly not small projects either.

The biggest advantage, I think, of unit tests is that they're repeatable; once they're there, you can constantly run them and make sure you're not re-admitting old bugs when you alter code. If it wasn't so darned easy to test stuff in the REPL (all the languages in which I program have one) or if it didn't take so much darned typing to make unit tests, I'd probably use unit tests. As it is, though, I can't even bring myself to write unit tests, let alone write them before I start coding on the project itself :)

One thing about test-first development is that it's still not optimal; there are better ways to write defect-free software. Look for some metrics on defects per line of code for different defect-prevention methodologies (like the metrics you'll find in, say, Code Complete) and you'll find that code review is far superior to testing at finding bugs. When I'm coding, I'm constantly reading my code to make sure it actually does what I think it does. When I'm writing good code (which isn't all the time by any stretch) it's so componentized and factored into small chunks that reading my code catches nearly all the errors latent in it. Breaking functions down into ever smaller functions makes it a breeze to read (and by so doing, assure the correctness) of code, IME.

I just haven't felt the need for tests in my programming experience. Maybe that'll change as I move further along in my CS curriculum, we'll see :)

Jeremy

[Dru Lee Parsec]

I've used the XP concept of "pairs programming" with interns and it does seem to bring a jr. programmer up to speed fairly quickly. But it also takes away all the time of the Sr. programmer.

The unit test part is interesting. I like the idea of programmers running unit test on their code and checking the test code into a version control system. Anyone who modifies your code must run your test on their modified code. If any of the old test fail then you better have a darn good reason!

I completly disagree with the idea of "Don't write setters and getters for attributes that you arn't using" You may not be using them now, but it makes sense to write a protective wrapper around your attributes. Besides, Jext has a getter/setter wizard so it takes about 5 seconds to write that code.

"Never work more than 40 hours a week". There's an XP concept I can get behind. After a year on the dot com roller coaster where I got paid half the cash to work twice the hours I like the 40 hour week idea.

[stuka]

Dru Lee: I'm fairly certain that the pairs programming concept is not really meaning a mentoring thing - though that's never bad! It really means that you have two programmers working together as a pair - these could be equally experienced programmers working together.

[recluse]

Personally I would love to have the opportunity to be a parrot on Dru's shoulder as he worked. ;)

Polly want a cracker?
Bwaaack!

[stuka]

From what nanode has said in the past, I'd agree wholeheartedly with that assesment, recluse.

[Strike]

Yeah, I never even thought of the pair programming paradigm (say that three times fast) as one for mentoring. But rather to assure things get coded well the first time. Kind of like "proactive QA" I guess. Where you have someone reading through your code even as you code it. Whether or not they actually input stuff is another thing entirely.

[stuka]

Well, in my CENG lab, my partner and I sorta do pair programming - we hack together assembly code looking over each others' shoulders, and it works pretty well. The other day we wired up an SRAM array, then wrote code to test it, and everything (hardware and software) worked on the first go.

[kmj]

I practice "group testing" when I take tests in class; that is, I look at all tests of the people around me and if their answers look better than mine, I use them instead.



<disclaimer>joking!</disclaimer>

[Dru Lee Parsec]

Personally I would love to have the opportunity to be a parrot on Dru's shoulder as he worked.

What nanode and I did (and maybe I misunderstood what the XP document said, but this is how we interpreted it) was we had two programmers with just one computer. nanode would "drive" by typing everything and I would tell him what to type and why. So as we would find, analyze, and fix bugs I would tell him how to test, why the bug happened and how to fix it and he would run the test and fix the bugs himself as I sat next to him and guided him.

There were many many times when I wanted to grab the mouse and say "No! Do It This Way!" (in fact, I did exactly that a few times). But overall it's kind of like a Sr. programmer downloading his every thought directly into the Jr. programmer. I know nanode came up to speed on our code really fast.

[inkedmn]

Originally posted by recluse
Personally I would love to have the opportunity to be a parrot on Dru's shoulder as he worked. ;)


agreed, definitely...

[stuka]

Dru Lee: from my understanding of the pairs programming, it's supposed to be far more collaborative than that - both people are working together on the code, but only one is 'driving' - kind of a pilot/copilot type of thing, instead of a driver/mother-in-law in the back seat kind of thing ;)