Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

djberg96 (2603)

djberg96
  (email not shown publicly)

Journal of djberg96 (2603)

Friday June 21, 2002
10:42 PM

Extreme Programming - personal experience

[ #5854 ]
This week I participated in a project launch where we used the practices of the much-touted Extreme Programming. This was a four day event that's just a "kickoff" for a 90 day project. It started every morning at 0730 and lasted until approximately 2030 each night.

The good points:

  • Simply getting the customers, developers and testers in the same physical area and forcing them to flesh things out seemed to work. Why this stuff can't get done through email, phone, IM, etc is beyond me, but this seemed to work very well. Note that I didn't mention "managers" in that sentence. Although they participated, they were invisible and contributed little or nothing to the process IMO.
  • Pair programming - this seemed to work well, as the guy I worked with most of the time knew the Tibco software much better than I do, while I was able to message parsing and some sql construction logic.
  • Accomplishments - stuff definitely got done.

The Bad Points:

  • The toolset - since our company drank the .NET cool-aid, we had to use Microsoft's Visual Studio .NET and, specifically, C# and Visual SourceSafe for version control. We lost a *lot* of time dicking around with version control the first day because our source control server was 1000 miles away (we got a local one set up the next day). It *literally* took 3-5 minutes for every check-in and check-out. Insufficient hardware, IDE navigation and unfamiliarity with C# also hurt.
  • Long hours - at first the developers didn't mind but by Thursday afternoon it became clear to me and others that it had become counter-productive. We were all getting grumpy and our minds weren't as sharp as we would like. Coding started to get a little sloppier.
  • Remaining questions - how often do you get to go back and tweak code that has been "completed"? I know lots of error checking (try, catch, etc) got dropped at the wayside. Would programmers ever get to go back and fix stuff like that? I'm not actually assigned to the 90-day project, so I'll never know.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I feel your pain about VSS, especially long distance. It's designed to be used on a LAN: very, very chatty. I think there's a product available to help out with this, but unfortunately I don't remember the name.

    To me, one of the most attractive things about XP is the constant refactoring. And not just "problem" code either: everything. If you come across code that "smells" [c2.com] then you fix it, right then and there. You don't need to request time to do it, put it in a queue of other fixes that will never get l

  • Once of the tenants of eXtreme Programming is "Sustainable Pace". Working to the poing of fatigue might be O.K. for a training session, but it sends the wrong message at a kick-off.
  • by ziggy (25) on 2002.06.24 7:57 (#9922) Journal
    Sorry to be the one to tell you this, but that's not Extreme Programming. That's Buzzword Compliance Programming. :-)

    It started every morning at 0730 and lasted until approximately 2030 each night.

    Extreme Programmers work 40-hour weeks. It's a basic tenet of the faith. :-)

    Occasional overtime is periodically required; two consecutive weeks of overtime should be avoided at all costs, and continual use of overtime is a sign that there's Something Very Wrong Going On(tm).

    Why this stuff can't get done through email, phone, IM, etc is beyond me, but this seemed to work very well.

    You want high bandwidth across the customer and programmers. There is no higher bandwidth than working face to face. Every minute you spend composing an email or writing a document is 55 seconds more than would be required to sketch a few lines on a whiteboard/napkin and say "Hey Joe, is this the way the code is supposed to work?"

    The toolset - since our company drank the .NET cool-aid, we had to use Microsoft's Visual Studio .NET and, specifically, C# and Visual SourceSafe for version control.

    There's an old saw about programming that you can only learn one or two new tools at a time. (Why do you think UNIX puts The Fear into newbies?) More than two, and you're setting yourself up for failure, or at least a whole mess of unnecessary headaches and pain.

    The XP way? Whenever you're about to delve into the unknown, schedule a sprint. Pick an unknown (C#, VSS, or VS.NET) and play with it until you're at least a little comfortable with it. Repeat until you can make an accurate prediction on how long it is going to take you to perform Task X with New Technology Y. Time used for sprints is budgeted outside the overall schedule (time out-of-band).

    We lost a *lot* of time dicking around with version control the first day because our source control server was 1000 miles away (we got a local one set up the next day).

    Extreme Programmers own their environment. Period.

    The XP Manifesto talks about little things like setting up desks so that two people can sit in front of one keyboard. If you cannot make that simple change to your physical environment (translation: mgmt. doesn't support you enough to tear down the cubes), then you're not Extreme Programmers (and you don't really have mgmt. support, a fundemental requirement).

    This also extends to real issues like the build environment. If you read between the lines, you see that XP is a set of mutually reinforcing practices to reduce the overall friction of development. Friction is reduced by removing those annoying little burrs that eat away at your skin, not by cramming more hours in the day (so you move the same distance, accounting for time spent bandaging your skin).

    So if you can't get mgmt. support to get a faster source code control server (a really fundemental requirement) or a dedicated machine that can build and test the entire project quickly (fifteen minutes, or about as long as it takes to get a cup of coffee), then you're not using Extreme Programming. XP requires buy-in from the mgmt. and the customer to speed the development process. Anything less, and you're just throwing around this week's fashionable buzzwords.

    Long hours

    See the first point. If you're not fresh, then you're not working at peak efficency. XP is intense only because it allows you to structure the project so that you remove all unnecessary distractions and time wasters. There is no greater time waster than being tired.

    Remaining questions - how often do you get to go back and tweak code that has been "completed"?

    Code is never "completed" in the traditional sense.

    Each iteration, you need