Fog Creek Software
Discussion Board




extreme self help?

Recent discussions on this board prompted me to stop in at the local Barnes and Noble to check out the Extreme Programming book series.

There were a bunch of good ideas in the books, and overall as a development methodology it seemed to have merit. Not my cup of tea, but I didn't see anything that stood out like it would sink a ship.

However, one thing did stand out. It sort of seemed like an undercurrent to all the books was "this methodology will help you cope with an extremely soul-crushing career in corporate information systems." The guys who wrote the books seemed to have a lot of experience building internal systems for car manufacturers.  When I had my dark days working on internal billing systems, certainly a pair programming partner and a 40 hour work week would have alleviated my desire to be run over by a bus on my way to work every morning...

My question is, does extreme programming apply to software projects that aren't completely horrible to begin with? 

extremely bored
Tuesday, May 07, 2002

As already stated on another thread, I tried and learned XP mostly on a hobby project. I love this way of working and find it to be very productive. So, my answer would be "yes".

Ilja Preuß
Wednesday, May 08, 2002

>My question is, does extreme programming apply to software projects that aren't completely horrible to begin with.

We work in telephony which I find quite exciting and challenging, especially since everything you do in telephony gets multiplied by 200 (one per phone line).  So scalability is a huge issue.

In this environment, there is one very boring thing -- testing.  Installing voice cards, firing up the system, make  phone calls, shut down, change voice cards, repeat. 

XP helps because it gets you to build 'testability' in from day one.  Most objects can be tested in isolation from actual hardware, databases, networks, etc -- all the stuff that slows you down. 

IanRae
Wednesday, May 08, 2002

Ian,

I am not surprised that building in testability is a big help to you.  But that is a common software engineering practice.  Just because XP picked it up does not mean that you can say "XP helps".

Maybe it helped in the sense that learning about XP is how you learned to do testing, but that doesn't mean you are doing XP.

mackinac
Wednesday, May 08, 2002

>I am not surprised that building in testability is a big help to
> you. But that is a common software engineering practice.
>Just because XP picked it up does not mean that you can
>say "XP helps"

Mackinac,

Are you saying that XP is not helpful because all of its "good" ideas can be found in other methodologies? I see the XP view of testing to be quite different from testing within other methods.

I am working on a project right now with a high-process architect. He claims to be in favor of testing, but we just don't have time to write tests (in his view).

In XP you make the time to write the tests. Although I see the danger of just writing test cases, I have not yet been on a project with too many tests! There is a line from one of the XP books. It goes something like : "If you aren't doing testing, you aren't doing XP".

Are there other methodologies which encourage (automated) testing as one of the main points?

Nathan
Wednesday, May 08, 2002

>>>"Are you saying that XP is not helpful because all of its "good" ideas can be found in other methodologies?"<<<

No.  That was not my intent, but looking back at my posting I can see how it might be interpreted that way.

What I was trying to say (hoping that it comes out right this time) is that the fact that one feature of XP is helpful can not be used to imply that XP as a whole is helpful.

  (testing) contained in (XP)
but
  (testing is helpful) !=> (XP is helpful)


A significant fraction of the posts on these XP threads are saying something like: XP is good because I like feature Y.  My impression is that a lot of those people are inexperienced and just never heard of feature Y until they heard of XP.

But I should also say that I see the extensive testing as one of the better features of XP.  So I think that "studying XP" can be helpful if it teaches useful techniques.  But that's not the same as "doing XP" as a whole methodology.

>>>"There is a line from one of the XP books. It goes something like : "If you aren't doing testing, you aren't doing XP"."<<<

That is consistent with the impression I get from reading some of the XP web pages.  But there are other practices besides testing that are needed to make XP XP.  Thus:

    (Doing XP) => (Doing testing)
thus
    !(Doing testing) => !(Doing XP)
but
    (Doing testing) !=> (Doing XP)

mackinac
Wednesday, May 08, 2002

>I am not surprised that building in testability is a big help to you. But that is a common software engineering practice.

Yes, commonly preached but seldomly practised.  And never practiced with the focus and tenacity that XP preaches (where you write the test as you write the code, and you do this for every class and every method).  Is there another methodology that contains this practice? I don't think so.

The subject of this thread is whether XP is useful outside of 'soul-crushing' IT projects.  I'm giving an example in telephony where it is.  I mentioned automated testing as one XP practice.  I should have mentioned others that have helped too: automated builds, continuous integration, do the simplest thing that could possibly work, release often.

>Maybe it helped in the sense that learning about XP is how you learned to do testing, but that doesn't mean you are doing XP.

An interesting question.  XP's strength is also its weakness.  My gripe with other methodologies (Rumbaugh being the one I'm most familiar with) is that they are a grab-bag of techniques with a lot of wishy-washy advice -- 'you may find event trace diagrams useful, you may find spiral development model useful, you may...'.  In trying to be generic they end up saying nothing much at all. XP is at least completely explicit about how to plan, how to write code, how to build, how to use version control, and how to ship.

But that explicitness means that almost no one "doing XP" is doing all twelve practices, or at least right away.  The practices cover the gamut from customers, sales, marketing, management and development.  Few developers (who are the most common XP advocates) have the power or influence to change these other departments.

So yes I am not doing XP.  But if you had to pick a name that best matched the approach I use then XP or XP-ish would be it.

>Just because XP picked it up does not mean that you can say "XP helps".

Very true.  In the end every team has to craft their own process.  It will never be all the practices and only the practices of one methodology.  The main thing I take from XP is it's respect for source code.  Good source code is really what it's all about and many 'gurus' have lost sight of that.

IanRae
Thursday, May 09, 2002

Ian, you have some interesting comments.  Many of the projects I have worked on would benefit greatly if better testing had been built in from the start of the project.

OTOH, some XP practices might not help so much.  The project I am currently on is very complex.  I doubt that it could have been built with the light weight design procedures of XP.

And I don't see pair programming as very helpful.  Code reviews, design reviews, even discussions in the hallways about design problems are all very helpful, but that doesn't mean you can scale that interaction down to the point where two people are overlooking every keystroke that gets typed.

mackinac
Thursday, May 09, 2002

XP is not for large projects IMO.  It's too social a methodology -- bigger teams than about 10 need other methods of communication, such as... design docs!

I don't do pair programming either -- it's the one XP practice I find hardest to implement.  However I generally move any hallway discussion immediately to a computer where everyone can see the source code ('this field in this structure *here*').

Cheers.

IanRae
Thursday, May 09, 2002

*  Recent Topics

*  Fog Creek Home