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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Extreme Programming is Misnamed 16 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • "Making Tons Of Money By Writing Down Linux's Internet Based Design And Implementation Method (But Without The Internet Part) And Telling Businesspeople It's Really Cool (Like OO)"

    • They got the Linux kernel wrong, then, as "refactoring" should be called "throwing it all away and starting over from scratch every release" and "automated testing" should be "ask users to debug it for you and berate them for not reading the development mailing list religiously". :)

      Lots of open source projects succeed because their leaders are exceedingly brilliant at project management without discipline. Lots more projects succeed because there's a point at which you can throw many, many warm bodies at

      • Free software is worker control. This means:

              1) workers aren't forced to work on the boss's bad ideas -- the bad ideas
                    have to attract the workers on their own (see apache.org java stuff :)
              2) no boss deadline pressure
              3) no boss backward-compatibility pressure

        These three things are, in my experience, responsible for the bulk of stupidity
        in boss-run proprietary software organizations.

        Now, of course,

        • But how can you say the Perl 5 guts don't have backward-compatibility pressure? :)

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

          • Let's not talk about backward pressure in guts, please. There might be children present.

          • Of course there is backward compatibility pressure -- but it doesn't compare to
            a proprietary shop, where the boss says "We can't lose this big account -- so
            don't change anything, anywhere, that might cause them problems."

            One of the reasons that proprietary software sucks in general is that the
            programmers are first rushed, then told not to change anything. Developers of
            free software have much more freedom to say "The next major version will change
            things; stick with the old version if you want; fork the pro

            • Right, open source software is less affected by economic pressure. That's probably the largest pressure that leads to an immature release, but it's not the only one.

              (Sidebar: This weekend, Ward Cunningham and I discussed the idea that open source's biggest advantage is not necessarily improved communication, it's scalability in the sense that a thousand hackers can throw themselves at a problem and a few might eventually come up with a solution. I'll continue to argue that practicing a little m

              • W.R.T. "scalability" -- thousands of hackers are not needed, and generally not
                involved. It takes only a few really good ones to solve a particular problem.
                And those really good hackers produce much better work when they have control.

                In my experience it is proprietary shops that use the "hordes of programmers"
                approach, trying to crank out software quickly by throwing lots of mediocre
                programmers at the problem. The "wizard in the tower" approach, though
                sometimes slower, gets better results.

                Now, one could
  • it's not extreme to you because you've already bought into it and you're looking at it from a smart developer's point of view. Of course small development iterations are good; of course forcing customers to choose features based on an honest assessment of the costs is good; of course continuous testing is good.

    IME XP really is extreme for old-school big-design-up-front folks. Or for people who think Big Serious Projects require one or more Serious Architects who dictate in the form of The Specification to the Small Developers what Shall Be Done. And then the project is 50% over budget and 66% late, but they keep doing the same thing over and over, because it's what they know. And it's not just old COBOLers either -- for an extreme reaction, just bring up pair programming on any development list or forum that isn't solely populated by xp-folks... :-)

    I do think the association with Mountain Dew, bungee jumping and crazy ski guys is unfortunate and causes people to have a bad first impression. Too late now...

  • Oh, I'd say it's partly about programming.

    Test-driven-development, pair-programming and a lot of the attitudes like you-aint-gonna-need-it and once-and-only-once are very much hands-on programming related.

    There is a project managemenet aspect as well of course. And somewhere the line is blurred, like YAGN; that's part programming design, part project management strategy.

    IMHO, and what do I really know?, I've never actually _done_ XP :) But I know I've had great success with TDD, YAGN and aggressive auto
  • This reminded me of Andy Lester's (just slightly tounge-in-cheek) "Extreme Mowing" article in The Perl Review: http://www.theperlreview.com/Issues/v0i5.shtml It's about how he successfully applies XP principles to mowing his lawn. I don't remember whether he had a test suite, though. And I don't think pair mowing would work too well; lawnmowers are designed to be pushed by a single person, and you can't really converse over the noise of the engine.
  • I don't view [Extreme Programming] as particularly extreme: it merely says "follow the good programming practices that you already know about".

    Well, not everyone agrees that each of the XP practices is good. A lot of people view pair programming as a waste of one programmer.

    Extreme Programming is one set of good practices which have been shown to reenforce one another. There are plenty of other good practices, but if you cherry pick practices and put them together without considering how they interact,

    • The strongest objections to pair programming that I hear usually seem to come from those who have little experience with it and those who prefer to be alone. The objections, in fact, remind me of an interview where the manager told me "we don't want you writing tests because that will slow down your programming." I was offerred the job, but I declined.

      Having done quite a bit of pair programming here at work, I've discovered that it can be a bit tough as many programmers are, shall we say, not overly soc

  • This is probably not a terribly original observation on my part, but Extreme Programming is horribly misnamed. I don't view it as particularly extreme: it merely says "follow the good programming practices that you already know about".

    That's quite a big "merely" considering how many people ignore good practices on a daily basis:-)

    I agree that, in hindsight, XP was a terrible name - but only because of the "dangerous" / ad-hoc / bungie-jumping connotations.

    To me the "extreme" was always intended to

    • Of the practices unit/acceptance test first, pair programming, collective code ownership, refactoring, YAGNI, etc. all seem related to programming to me :-)

      As from from test first programming, those seem applicable outside of programming.

      • YAGNI -- painters don't do extra fancy trimming unless asked.
      • Pair programming -- people working in teams to check each other's work.
      • Collective code ownership -- rotating accounting personnel through various deparments so they can see the whole business.
      • Refactoring -

      • I think you're reaching on some of those :-) For example you get a lot of synergy between the XP practices in programming that you don't get in other fields (it's hard to refactor a damp-proofing layer if you're a YAGNI painter!)

        I stiill think the XP practices are more about programming than project management.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.