This came as a shock to me because I've been analyzing and solving problems for a long time: I escaped Engineering school in '68, '70, and, finally for good, in '72. We didn't have 'design patterns' then. We had principles, experience, and knowledge.
So what are these things? Are they a good thing or not?
According to the Wikipedia article on Design Pattern (computer science), a design pattern "... is a description or template for how to solve a problem that can be used in many different situations."
So far that sounds good, but then I start getting confused:
- design patterns are not algorithms because "algorithms solve computational problems." I didn't know that. I thought algorithms were systematic, iterative procedures which did something - like copy a buffer from one place to another or to find something.
- design patterns are not "architectural patterns" because they have a "different scope."
Then I read some stuff by Martin Fowler describing the Active Record pattern. The thing that came across most strongly is vagueness. Everything is so indefinite and "could also be ...".
It all became crystal clear!
Design Patterns are the current Holy Grail of the Software Methodology Guru.
As long as I've been beating on computers, there have been Great Gods of Software Design. I used to read their stuff and think I was doing everything wrong because I wasn't doing it their way. So I'd try it and it didn't work very well for me (why later).
The Software Methodology Gods are really OK guys, but you have to judge their gospel within its context. In other words: what do these guys really do?
One thing the don't do is actually build the kinds of systems they tell you how to build. Why? Well, they don't have time. They spend their time watching other teams build things and writing and preaching about what they've observed. At least that's what they are supposed to be doing. [And the reason it didn't work for me is that I've never worked on a team. All my stuff was in-house, solo or with a partner, limited scope, and very limited user base. Their experience did *not* apply! see Joel on Software, chapter twelve "Five Worlds"]
So these guys' main business is giving advice.
I'm sure a lot of the advice is pretty good - it has to be if they get from watching teams that do good work. But that doesn't mean it's right 100% of the time and in all cases. Anyway you can't really tell if it works, because there's no way you can compile and execute vagueness.
OK, I'm a little harsh. It's just that if the advice is vague, then it's usually pretty easy to win the postmortum no matter how things work out - success or failure. If it worked, it's because you followed my advice. If it failed, it's because you didn't. Vaguness covers or excludes a whole range of implementations.
Anyway, what happens is this: These guys sound so confident that I used to get lulled into thinking that they're right and I was wrong.
What's the result?
I'd read their stuff and instead of trying to figure out if it is worth doing in my situation, I'd spend all my time trying to figure out what they're talking about and how to change what I was doing to be right - according to them.
I was working my brain, but not on the right problem. (By the way, would you be interested in this really great vacuum cleaner we have on special today?)
So, here's what I think Design Patterns are good for:
- ideas - look them over and see how somebody else does it
- obfuscation - if you know enough of them, you've got a great cryptic language you can use to blow smoke in the other guy's face
- writing books and articles - "Design Patterns for ________". Just fill in the blank and you're all set for fame and fortune
- getting consulting gigs from non-technical managers
- giving courses to programming teams
One thing they won't do is make mediocre and poor programmers productive.
So what am I going to do now? Well, I'll read the book. There must be something useful in there. But I'm not going to shut off my brain when I design something.
No comments:
Post a Comment