XP – Extreme Programming

This is an english post because it’s related to iJigg and crazy programming way of life.

Okay, first of all, what the hell is XP?

XP stands for Extreme Programming, it’s a phylosophy about how to create things faster without losing quality. That’s weird because speed is in an opposite side of quality on development equation.

XP says:

1. Pair programming (crazy, hard to do, but it works)
2. Work on simple/small things first
3. Create the tests even before you start coding (I never did it, you need a test team)
4. Doesn’t matter how ugly the code will look as far as your pair understand it, you can make it look better later
5. While you code, your pair will document

Okay, iJigg is a mental challenge. I learned a lot of things like mysql built in search engine, flash stuff, perl performance tips, etc.

But Zaid always has a great idea that makes my life harder… that’s why I think designers and programmers will fight forever. It’s like the architect and the engineer… Architects always has crazy ideas and the enginner has to do the math to make it happen.

Okay, good looking and simplicity is what matters at the very end, so Zaid asked me to put a flag on the latest element of few lists we’re working with.

When dealing with lists in perl I don’t like to use counters or stardard loop functions, so I don’t have any idea which is the last element because I had never needed to know about it. But, DANG! Zaid asked me that.

Okay, time to find a way to do it without having to code many lines… I mean I’m lazy I wanna code one line.

That’s what I did:

$random[$#random]->{isLast} = 1;

After the loop I just got the prepared list, find out the latest element ($#random) and set the flag on a hash reference inside the list.

I love XP, I love perl, I love challenges.

1 comment

  1. Whoa! I’d like to add my thoughts to this one 🙂

    Having worked with the XP way of life to varying degrees of effectiveness in the past, one of the most important things about it – if not the most important and easily overlooked aspect of the methodology – is, it only really, really shines when used in full.

    More often than not, when asking “so, do you do XP?”, I’d generally get the answer “well, some of it. we have our own process, incorporating as we go”, which would generally mean an awkward, counter-productive development process in which some of the time, when schedule was kinda loose, devs would pair up to do some work.

    I cannot stress the following statement enough. This is not XP.

    XP is a development methodology – and like every other, works as intended when used as it’s supposed to. That is, in its full.

    XP takes some things to – as the name suggests – extremes. It’s not your everyday way of developing stuff. You need good, experienced coders and, most importantly, reasonably versed in the methodology.

    It works faster because it cuts the crap that plagues common developer practices. It sticks to things that matters. It’s not every number-freak manager’s cup of tea simply because it’s pretty damn realistic. Requirement word docs don’t mean anything until you sit down and start proving your idea actually works.

    Furthermore, XP is not cowboy coding. In fact, it couldn’t be farther from it. XP relies on solid, strongly disciplined (test-first) coding, even when things are tough and schedules are frightening. Writing test first doesn’t require any additional people. What you do is (hopefully, using some ported unit-test library for your language of choice) just, before writing the actual code, writing code that asserts that what you intend to do. *A bug means either you haven’t tested everything or, your tests are missing something*.

    It seems impossible and/or overwhelming and a stupid waste of time at first, but as you get used to it, you’ll eventually realize the power that this test suite holds. It not only acts as your documentation, since you’re actually testing everything that could break, but also as a regressive, automated suite of tests that ensures (or at least helps to) that your stuff is working the way it should, and no more than that.

    Weird code sucks. Bad code smells. One of the most overlooked aspects of XP is refactoring. Write the test. Write code that passes the test. Refactor mercilessly. Before you get to the next feature/test, your last chunk shouldn’t be a mess you wouldn’t show your mom with pride. Since you can cheaply run the automated test anytime, you can confidently evolve the initial requirement into a neat, elegant piece of code that makes your mama smile. Two points if it’s in written in ruby 😉

    Work on the simplest thing you can implement. Write the test for it. Code for the test to pass, and only that. Then, remove the smell. Rinse and repeat.

    Oh. And Perl is one hell of a language. But as you can guess, ruby gets me through my day. Eventual holy wars being most disencouraged 😉

    And oh, by all means, keep up the good work!!!

Leave a Reply

Your email address will not be published. Required fields are marked *