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 ]

Simon (89)

Simon
  simon-use-perl@perlhacker.org
AOL IM: lathosjp (Add Buddy, Send Message)

Busy Man.

Journal of Simon (89)

Friday March 22, 2002
03:03 PM

Kool-aid

[ #3728 ]
I hate Design Patterns. I hate XP. I started wondering why I hated these things, which are actually relatively reasonable taken out of context.

The first problem with them is that they're amazingly obvious. Code review never stopped being a good idea, and telling me that it is isn't telling me anything I don't know. A lot of coding theory ends up like this, because you're essentially preaching to the choir.

The second problem is that they build up this amazing cultish following behind them, that Design Patterns are the only way to program, and you're obviously an incompetent coder if you don't follow the XP guidelines to the letter. Hey, doesn't this sound just like the Object Orientation mafia? It is. Well, fuck that, I was planning to do things that way anyway, koolaid or no koolaid.

Finally, you can't get away from the way they name things. You can't just have three classes interacting any more - one's a Model, one's a View and one's a Controller. Always with the Capitals.

And then it hit me. Design patterns and XP are just another form of voodoo practice - they're cultish belief systems which take perfectly ordinary concepts that we used all along, and then Name them in order to derive power from them. Voodoo programming, that's what it is. And you thought cargo cult programming was bad...

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.
  • Sipping the kool aid (Score:3, Interesting)

    by ziggy (25) on 2002.03.22 15:21 (#6234) Journal
    The first problem with them is that they're amazingly obvious.

    [insert the obligatory quote here about the earth revolving around the sun being obvious]

    It is sad that there are some obvious practices that need to be blasted to the hills. The first instance of what we now call pair programming I've seen dates back to the 1960's, and a lot of the writings between then and the dawn of XP talk about removing the ego from programming. Pity, that.

    Sometimes these ideas are obvious, and sometimes they's a dominant and prevalent anti-pattern in the way. (Which is a very modern way of saying "most people are dumb as dirt".)

    Anyway, I personally believe that there is merit to XP and Design Patterns, except when they get made into a religion. Thankfully, some people [sdmagazine.com] are rethinking their relationship to the Church of Gamma, et. al. Perhaps there is hope that someday soon, these movements will lose their religious ferver and simply become obvious ideas.

  • For me, the main value of design patterns is not so much in explaining new ideas to me (because most weren't new when I read the DP book) but they give programmers a convienent shared vocabulary to talk about this stuff.

    So I don't have to say "I have a class that kind of, you know, makes other objects, based on various parameters, and it knows how to select which object to make based on various criteria."

    Instead, I can say "I have a Factory class" (feel free to spell that as "factory" ;). That is where i
    • I had a software engineering professor who would not believe Perl was an object-oriented language. I tried to explain it had been so for over five years (at the time) and that there was a lot of obsolete literature out there giving wrong information. He thought I was just referring to some super-disciplined ultra-structured technique, much like you might do "object-oriented" programming in C (or even assembly, he said).

      Then one day he had a class on design patterns. He explained the Factory pattern as

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Yes, but... (Score:3, Insightful)

    by Elian (119) on 2002.03.22 16:25 (#6239) Homepage Journal
    Much as I also loathe the hype and cultishness surrounding XP, its presentation is probably the most effective way to get it to most of the people who need it the most. Like it or not (and I don't) programming isn't an engineering discipline. If it were, none of this would be necessary, but it's not so it is. It's mostly a craft, most of its practitioners like it as a craft, (to its detriment, but that's a separate problem) so craft approaches are the best. Consider XP the freemasonry of programming.

    Whi knows, we might even get a Secret Handshake out of it...
  • XP, DP, and Chess (Score:4, Insightful)

    by Ovid (2709) on 2002.03.22 17:34 (#6245) Homepage Journal

    I used to play chess a lot. So much so that my ex-wife referred to herself as a "chess widow". I learned a lot of things from chess and I think the single most important thing that I learned was this: given two players of equal skill, the player with a bad plan will usually beat a player with no plan.

    It's interesting the choice of topics you chose to vent about. XP tends to deal with strategy, while Design Patterns tends to deal with tactics -- the overall game plan versus the actual moves. You have to know both. If you take a team of exceptional players in their given sport, they often underperform because their tactics can be brilliant, but they tend not to follow any strategy. How many sports teams do we know that can't seem to win because they don't grasp the concept of "team"?

    I had a brilliant boss won time who was one of the finest coders - tactics - that I have had the pleasure to know, but he had no clue as to how to manage a project. Further, he couldn't seem to grasp that other programmers didn't have his phenomenal ability. Oh, he would say that he understood this, but if someone (me, for example), made a stupid mistake, he would ream them a new, uh, something or other. The company itself was floundering because they had good coders who just couldn't figure out how to work together.

    So, what does all of this have to do with XP or Design Patterns? Many people just don't get the concepts. I was reading Code Complete recently and it mentioned how about 100,000 new programming positions are created every year, but only about 40,000 CS graduates enter the market per year. Let's face it, while CS graduates don't necessarily understand the real world, they are often better prepared to meet many challenges that some "I just made my first Web counter" programmer. Regardless of whether or not we agree with the principles that these things espouse, or the terminology they attach to things, I think many people are better off adopting them than adopting nothing.

    I think you're perfectly correct to vent, though, about people who find out about XP and Design Patterns and follow it religiously. Oddly enough, I have a long rant [easystreet.com] on my Web site that touches on this topic, though obliquely. The essense of it is this: once people find something that works, they tend to lose sight of why it works and, instead, simply follow it blindly.

    It's a sad, sad thing.

    • Your analogy is interesting, but I'm curious -- why did you categorize Extreme Programming as a "Strategy" and a Design Pattern as a "Tactic"? I would think the reverse is the case.

      As I see it, a “Design Pattern” (DP) is an over-all strategy which can be applied to a problem, to which many different tactics for implementing that strategy can be utilized.

      In this scenario, “Extreme Programming” (XP) would be a tactic. It is a specific means by which to implement the larger strate

  • Design patterns and XP are just another form of voodoo practice - they're cultish belief systems which take perfectly ordinary concepts that we used all along, and then Name them in order to derive power from them. Voodoo programming, that's what it is.

    What's that got to do with voodoo? Why not same it after another religion with sheer obscuranist oomph? Like "Catholic programming"!

    Or "Islam programming"!

    Oh, I could go on all day; just call it "religion programming".

    Maybe we could commission [bridgebuilding.com] Robert [bridgebuilding.com] Le [middlebury.edu]