ExtremeProgramming

ec2-3-21-97-61.us-east-2.compute.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic

Just the NAME makes me sick.

Which is a shame, since it's actually a bunch of obvious ideas.

Work in a small team.
Rewrite often.
Test a lot.
Don't worry who 'owns' the code - if it needs fixing, fix it.
Don't spend overlong on the initial design, it'll be wrong anyway.
Don't be too constrained by your interfaces - they can be wrong too, so fix them if needed.
Get SOMETHING out the door FAST - even if it doesn't do everything.

(PeterTaylor) You missed the one about throwing away your old code rather than fixing it. That's what I really dislike.

Bullet two: "ReWrite?". And, as always, a middle path is the best option. You need to know when code is so tangled that a ground up rewrite is preferable to trying to make clunky code work that little bit better or harder. But you also need to know when you can re-use old stuff.

: To my mind "rewrite" is not as strong as "rm -f".

A concept ripe for appearance in PhoenixFeathers.

A Saturday-morning cartoon where two geeks throw away their pizza boxes at the signs of danger in the internet and shout 'Program X-Treeeem!' and are transformed into, well, geeks with penknives and screwdrivers and suchlike sticking out of their arms. And they don't have Crystal in a satellite either.

There's already one magical girl transformation in PhoenixFeathers. That's sufficient for any webcomic, IMHO :) - SunKitten

I have a horrible thought that this actually exists. Slightly different battle cry, but close enough. The standard five colours of teenager jump in to save cyberspace. LiveAction? cafe sequences and CGI cyberscape. Almost as bad as CaptainPower. American. NotMyFault.

Yeah. It does exist. I found it again. It's called VRTroopers, there are only three of them who transform and they have a sarcastic talking dog. It is awful. Truly truly abysmal. --Vitenka

: I remember that; like PowerRangers?, but somehow tackier. -- TI

Most of the ideas are not _that_ obvious - the 'program in small teams' one means two people to each monitor. Literally program in pairs.

: Um, that's hardly a revolutionary idea. It might be revolutionary to business - but it's certainly not that unusual before then. --Vitenka (Heck, I've even used it well in a business setting before I'd heard of XP)

I actually purchased the books 'CodeRefactoring?' and 'DesignPatterns?'. They are actually kinda interesting. Sadly, they are something that has to be applied from the start of a project and that has to be applied across the entire team. The ideas certainly seem attractive to my natural way of working, though. --Vitenka

(PeterTaylor) DesignPatterns? are well worth knowing about, although most of the DP stuff I've seen could do with a few more examples. E.g. the DesignPatterns/Visitor? is highly applicable in writing compilers. Most other places you see it used, it's functioning as a substitute for overriding methods.

: The examples seem to just be there to be enough to 'get it'. The really important bit, surely, is the 'what is good and what is risky' about each pattern. Having an extended common vocabulary is also valuable, even if it's not the optimal one. Having said that, every pattern I've seen (not read it all yet) is in some way 'obvious' and regardless is one I've at least considered before. What would be really nice would be a logic for combining them, letting you derive useful results from "that won't work" to "You can treat that combination as a factory" or whatever. --Vitenka
: This may be the time to point out that the first Wiki was originally started as the WikiWikiWeb: PortlandPatternsRepository, and has *lots* of interesting reading on WikiWikiWeb: DesignPatterns and suchlike. --AlexChurchill

Is that Fowler's Refactoring, and the Gang Of Four's DesignPatterns?? Both excellent books but not Extreme Programming. In fact, Refactoring is how you 'improve the design of existing code' and I think certainly not required from the beginning of the project. --Mjb67

Oh yeah - before seriously thinking about the practicality of using patterns, I recommend reading Gabriel's 'Patterns in software'. Another patterns book, Antipatterns, is an amusing and useful read: ISBN 0471197130 .

: Yes to both 'is that this book' questions. Refactoring definately is one axiom of XP. Patterns, maybe not so. But the language is often used in that context. Refactoring isn't required from the start from a code pov, but from the 'let me modify this code please' pov it is, sadly. Will look at the others certainly. --Vitenka

I clicked on this expecting it to be some variant on ExtremeIroning? - a bunch of geeks take a computer up a mountain and write the greatest code in existence. --Requiem
Maybe this is a context in which we ask somebody to remind us of the CrashAndCompile? contests... --AC

I've recently heard it described as a 'circle of snakes' - a bunch of dangerous and highly risky practices - turned up to eleven - which keep each other in balance. The idea seems to be to take a 'more is better approach' to everything. Of course, once one thing goes wrong, all hell breaks loose since the snakes are venomous. --Vitenka

Pallando worked briefly for a company that mandated that ALL their production code be produced via ExtremeProgramming.

   * two at a terminal - worked well
   * release(internally) early and often - worked very well
   * no code ownership - was a good thing IMHO as it penalised undocumented messes
   * minimal design phase - seemed to be ok (counter-acted by strong coding guide lines)
   * rewrite often - was taken to silly lengths (see below), might have worked in moderation
   * test first - not just test a lot, test FIRST.  This sucked (see below).

It could be just the way that particular company implemented the ideas, but they decided that not so much as a comma or test for a bad argument could be added to the main code, until you had already written a test that required that piece of code to exist. This lead to, in my opinion, an unnecessary amount of rewriting of things that should have been done correctly in the first place, because you could see they were going to need to be there eventually.

: The TestFirst? idea seems to be fairly popular. I can't really say how useful it is, but (with a convenient framework for writing tests) a quick play shows that it's not too awful, and could even be quite good if I could persuade Eclipse that it's a good idea. I don't think it interacts very well with minimal design, though; you'd get what you saw. I intend to keep fiddling with the idea in my CopiousFreeTime. --NT

CategoryComputing