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 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 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.
Re:Value of Patterns
jdavidb on 2002-03-25T04:52:21
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 an example; it seemed new to pretty much everyone in the room. I piped up with, "You can do that in Perl." His eyes just about fell out of their sockets! "You can?" "Yep. I was working with something a little like that this morning..." I think at that point I finally had him convinced.
(Of course, just to really drill the nails into the coffin, when I attended masters' project presentations by two of his students who both listed the same eight virtues for using Java as a language for mobile agents in a hospital environment, I made sure to let him know Perl had all the same virtues.)
It's not advocacy; it's self defense.
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 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.
"XP" and "DP" as Evil Tools[tm]
jerlbaum on 2002-03-27T13:21:52
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 strategy, which is to apply your DP to your particular problem.
That said, allow me to state for the record -- I’m 100% with the original author on the issue of “XP”. Extreme programming is a simple mechanism for enforcing good software project management techniques. XP’s most well-known and controversial feature -- dual programmers -- is (as the original author identified) just a mechanism for enforcing peer review. Peer review is a good thing, and if you don’t do it, you should!
Should you do so by implementing XP? Well, I’m not so sure about that. I work at a small company which could not afford to hire two programmers to do the work of one -- even if the resultant work is substantially free of flaws. In addition, my company has been working on improving our software process for many years, so our normal defect rate is pretty low, as it is. We already use many specific, codified, written and experience-proven project management techniques which contribute to our ability to make good software. We are also continually measuring our performance and engaging in process improvement. In our situation, enforced peer review of the nature that XP recommends would only be a marginal benefit -- not the 100% improvement required to justify the cost.
OTOH, if your organization has an undefined software development process and very high defect rates, paying two programmers for the work of one might actually give you the 100% improvement necessary to justify the cost. “XP” is intended to be a “package” of software development techniques. Think of it as “good software development process in a box”. It’s good enough, and for an organization without any plan and without anybody who wants to make a plan, XP is better than nothing.
Now, “Design Patterns” is a different story. I agree with the original author to the degree that “DP” is simply the way that we all do things, which has been given a name. However, I do not share his vitriolic opinion of the purpose of giving it a name!
The original author said that design patterns “take perfectly ordinary concepts that we used all along, and then Name them in order to derive power from them.” That’s pretty cynical. I guess you could say that of *ALL* documentation! “Everybody stop writing POD! By writing POD, you’re taking the obvious use of a module, and codifying it in order to derive power from it! All programmers should start by reading the source code -- no exceptions!”
If writing down a good idea is a bad thing, and if “deriving power” from a good idea is a bad thing -- then I don’t know what a good thing is! And that’s all that “Design Patterns” are -- a collection of OBSERVATIONS made over the years by many, many programmers. (Some of them may even have been smart!)
Now, there may be people and organizations which throw around terms like “XP” and “DP” like just so many buzz-phrases, in order to confound non-techie managers, and create FUD. That’s no different from people who say you have to use [Java| C++| XSLT| Whatever] if you want to write “Enterprise” software (whatever THAT is). There will always be people who misuse specific terms for that purpose. Does the fact that a sales guy says “only JAVA can be used for REAL software” make Java BAD? Of course not! Likewise, just because the term “DP” is bandied about by a shill, doesn’t make it a bad thing.
And design patterns ARE a good thing! Long before I bought a copy of “Design Patterns Elements of Reusable Object-Oriented Software”, I was coming to the conclusion, as a programmer, that I was seeing the same basic structures again and again. I would encounter a problem and realize that the solution was a certain type of structure, similar to one I used on an earlier project.
When I wrote CGI::Application, I didn’t know about the “Template” design pattern. Quite the opposite! I set out to write a module which would solve my problem. Long after I wrote it someone pointed out that my essential structure was strikingly similar to one which was documented. I read the definition and it actually helped me better understand why some ideas in my module worked, and why others didn’t! It has helped to guide my ongoing work on CGI::Application, to the benefit of all the module’s users.
As someone else in this thread said, the purpose of documenting design patterns is simply to create a common lingua for describing programming ideas. Nothing more -- nothing less. It’s not ominous, corporate, or evil. It serves the same purpose as a book, a man page or a conversation. Putting it in writing *does* allow us to “derive power from it,” and that is unquestionably a good thing!
Warmest regards,
-Jesse-
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 Robert Lentz to do us up an ikon of Kernighan!
