Fog Creek Software
Discussion Board




Cool Stuff


I'm writing this from the O'Reilly Open Source Convention.

I am currently sitting in the 'day of Extreme Programming' session, which is about to start.  (I'm connecting to the web on O'Reilly's Wireless network, which they have hooked up to the first two floors of the hotel for free.  free.  freee ...)

We'll be using CVS and Perl.

Do you guys have any questions you'd like me to ask?  Or anything else cool you'd like to talk about?


regards,

Matt H.
Tuesday, July 08, 2003

Ask what are the most common issues with extreme programming which, if not handled correctly, will cause it to be less than a success.  I guess that's a "most frequent failures."

Thanks for inviting questions, Matt.

van pelt
Tuesday, July 08, 2003

The most controversial part of XP is Pair Programming. If I understand PP correctly, a developer shouldn't be coding unless he's with his shadow. However, those who've experienced PP also admit it's more draining than independent development, and that they really can't go more than a few hours of PP a day.

Add to that the idea that in the real world it's unreasonable to expect your pairs to be in the office at exactly the same time (traffic, etc).

Do these constraints offset the gains of pairing? The burden is already on a pair to produce at 1.5-2x that of an independent dev; add in the stress factor and coordination restrictions - is there still a payoff?

Philo

Philo
Tuesday, July 08, 2003

My question for them:

How many shops out there actually USE extreme programming? Can they name a major, high profile company that honest-to-goodness uses extreme programming? How many persisted with it? Can they name any major large-scale projects that succeded, using extreme programming? (NOT C3 - we've all heard about C3 ad nauseum, thank you).

By the way Matt - thanks for this - it indeed is very cool! I'm looking forward to this.

Burninator
Tuesday, July 08, 2003


I'll try to get to some of the those questions; it's a practical thing, not a theory thing.  I think, in the end, I'll have more to add about how it worked for me than philosophy.

Of course, we can talk about it here on JoS.  I'll see what I can come up with.

regards,

Matt H.
Tuesday, July 08, 2003

How many Pair Programmers read Joel On Software Forums or Slashdot together? Does that improve their productivity?

;-)

runtime
Tuesday, July 08, 2003


Lunch time break.  Time for an update.

With XP, who you pair up with doesn't matter.  If you have an odd number of developers, that's good - pairs occasionally need to bring in a 3rd when struggling with an issue.

So, if your partner leaves for a dr's appointment, just switch - or, if no one is available, the coach can step into a coder's role for a bit.  (If you have a player/coach.  Heh)

After having one of the best times of my (coding) life this morning, I have to say that I think a HUGE part of making PP work is having the right environment.

We are using CVS, and I'm SSH-ing to the server, and editing the files with VIM.  Testing is using perl test and make test.

If I had to do something loopy like FTP the files to my PC and then back, and run some slow, long, boring test harness that required lots of input ... the whole thing would fall down.

Also, I'm finding that a large portion of the time is spent with integration and testing issues.

My estimate for something might be 30 minutes, and someone else might say "Why?  You should be able to do that in 5 ..."

Well, that might be true, but i'm not just writing the method.  I'm writing the test, running it, watching it fail, writing the method, running the test, watching it -still- fail, fixing the code, running the test, running cvs update, running the tests, then either telling people if the other's people's check-ins failed, or, committing.

Then, the committ will have errors, so I have to fix some things, then I re-run the test and try to commit.

In the end, it took 30 minutes.  Strange, hmm ? :-)

The flip side of that is that, after 2 hours, my team has conflicts. :-)  Luckily, XP minimizes those conflicts.

I'm having a complete blast so far.  I'm sure PP won't work for some, but man, people that just PP without trying it sure don't get it.

More later,

Matt H.
Tuesday, July 08, 2003

>Ask what are the most common issues with
>extreme programming which, if not handled
>correctly, will cause it to be less than a
>success.  I guess that's a "most frequent
> failures."

So far, it feels like #1 is "lack of committment" and #2 is "bad environment"

Oh, another cool thing: Done right, the customer/coder relationship changes from enemies to team members of the same team.

At least, that's the theory.  After actually TRYING it for a morning, I can now "get" how it would work.

regards,

Matt H.
Tuesday, July 08, 2003

I remember looking thru Questioning Extreme Programming.  Seems fair, though I dunno if it raises any points we hadn't heard about.
http://www.amazon.com/exec/obidos/tg/detail/-/0201844575/qid=1057695957/sr=1-17/ref=sr_1_17/002-9177008-9710441?v=glance&s=books

I was reading Guido van Rossum's blog and he mentioned that emacs' programmability made it painful when he tried to pair program.  This was in his review of The Humane Interface.  I wonder how it works if someone is a vi nut and another is an emacs zealot.  Maybe it will open their minds. ;)

Maybe you could ask how Parrot's going, whether it's turning out to conflict with or support .net.  If it's any interest to you...

sammy
Tuesday, July 08, 2003

"So, if your partner leaves for a dr's appointment, just switch - or, if no one is available, the coach can step into a coder's role for a bit.  (If you have a player/coach.  Heh)"

Uh, okay - they just lost me. Doesn't that mean you spend the first hour explaining to your new partner what you were trying to do?

Philo

Philo
Tuesday, July 08, 2003

Philo: in practice, that happens a bit. The idea is that since you have a small team and everyone knows what's going on, you just tell the new guy that "We're working on the frobonic gizzle.". That's possible because the features to be added for this iteration are known at its beginning.

In theory 8-}

Mike Swieton
Tuesday, July 08, 2003

XP kinda has the notion of "if practice XXX doesn't work for you, feel free to modify or eliminate it".

Which leads to the question -- how many best practices can you change and still claim to be doing XP?

And why do you need to label a methodology at all?  Aren't each of the best practices of XP independently good by themselves?  Can one abandon the organized religion of XP and still find salvation by petitioning the individual gods by themselves?  (I believe so -- but I'd willing to hear from others with other viewpoints)

Alyosha`
Tuesday, July 08, 2003

I want to know what happens in seven years when the maintenance programmer needs to see the design of subsystem ABC.

I second Burninator's motion to provide an example of a large system built using XP.  Has XP actually been used to create a large, multi-user, mission-critical system?

I'm not trying to bash XP.  I have not had any experience with it, but it seems most suited for smaller projects, and I just wanted to know if it has been used (successfully) on any large projects.

Dave
Tuesday, July 08, 2003


heh.

A large project is just a bunch of small projects strung together.

As for "design docs". I've found that REALLLY well factored apps don't need them.

Once you scale up part about 50K lines of code, though, I dunno.  Every project I've worked on that was that size had design docs and was Big Design Up Front.

THEN AGAIN, by the time the maintenance man would come along and ask for design docs, they were all HORRIBLY ineffectively out of date.

If they really existed at all.  Some of the cowboys on our team never wrote design docs - or didn't share them.

ymmv.

Matt H.
Tuesday, July 08, 2003

How often have you seen comprehensive, accurate, easy to read designs? My experience has been "never".

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, July 08, 2003

Actually what am i saying, I backup my emacs changes like keybindings, so I can just call restore-orig-bindings.  Something very programmable is its own salvation; it should be trivial to press a hotkey and switch to someone else's prefs.

sammy
Tuesday, July 08, 2003

Ask them if they have any free beer...


Wednesday, July 09, 2003

I agree with Matt -- when working with a large project design docs are helpful to get the wide scope. But they get out of date and are usually so rarely updated that it can actually  be more misleading to read them than not have them at all.

I think a good combination is high level docs in a wiki, or even something similar to Javadoc package documents, along with well factored code. The high level docs describe components (or families of components) and general interactions among them and the code hopefully describes itself.

A smart IDE that makes it easy to navigate around is a godsend as well -- having the ability to jump directly to a method, see the classes from which it inherits, etc.

Chris Winters
Wednesday, July 09, 2003

I'm with Chris. You need to have some sort of scope documentation on large projects or you risk a lot of wheel spinning. A wiki works wonders for this type of stuff. I se SharePoint and it has been a godsend.

Marc
Wednesday, July 09, 2003

Design documents are artifacts. I see the main role of design documents to force you to think about what you're about to do. In particular, I'm no fan of keeping up to date UML diagrams and other such artifacts - when they're out of date, I toss 'em in the bin. They're often largely fantasy anyway.

I admire a lot of things about extreme programming (many of their ideas are just established good practice), but I have a sneaking suspicion that the main reason extreme programming is successful is because it makes people work hard. You can't slack off. There are people watching. No surfing slashdot, JoS, or fark.com. No chatting with your friends on IM all day. You have to do actual work. 

And I think that's a good thing - although of course, ideally people should simply be more self-disciplined, but thats a whole 'nother thread.

Burninator
Wednesday, July 09, 2003

i concur with burninator. the guys who thought up extreme programming are guys who build billing systems for general motors. i've been in a job like that, and what I did was surf the web and AIM 7.5 hours a day, and spend the other 45 minutes writing 4 lines of code. having another fatguy looking over my shoulder would have probably forced me to focus more on the work. it is a methodology well suited for programming tasks no one really wants to do. 

bumpy
Wednesday, July 09, 2003

*  Recent Topics

*  Fog Creek Home