Re: Design Patterns Still Aren't

[chunlou]

Besides prior training, I found the success or failure of introducing and using published patterns in the workplace have a lot to do the the culture and personality of the team.

I met a development team led by several Swiss programmers, they did everything by the book, Java and Java patterns all the way. Practically everything they code is according to some associated published pattern. They're like airplane engineers and their codes are very robust.

On the other hand, a lot of Web development houses seem to be a bit more on the artistic side than engineering side culture-wise. Many of them kind of abhor the idea of using someone else's ideas (i.e. patterns, reusable solutions). They prefer self-innovation.

But every programmer uses "patterns" unknowingly anyway, the minute they reuse their own solution they used before, whether or not they have a name for it. Nothing inherently good or bad about patterns. It's just a way to solve problems.

_______________
Incidentally, a Perl programmer happened to review an application written by those Java programmers. He called the application "overdesigned" since there're some 200 Java classes (the ones they wrote on their own) sitting on top of slightly less than 20 database tables. Quite a contrast on design philosophies they have.

[menolly]

Part of the problem, I think, is overly simple examples. It's necessary to simplify in order to manage length and clarity, but when it comes to patterns, what I mostly see are examples that make it look like a lot of extra work for little or no gain. Web development tends towards the rapid development end of the spectrum, so it's difficult to grasp why we'd want to jump through all these hoops. It appears to be the sort of increased complexity that can help long-term maintainability if everyone involved understands it, but can harm it for someone new coming in, unfamiliar with the patterns in use.

[chunlou]

Right. A common problem is not so much about what is taught but how it's taught.

It causes a lot of resentment when the teaching of, say, UML, CMM, patterns, or what have you, is done independent of what the programmers are currently working on, instead of complementing it. (A programmer is pressed for deadline; it makes no sense to him to be told and taken away to attend a lecture that didn't help him make the deadline.)

It happens frequently when the instructor (especially the outside one) teaches based on whatever preestablished syllabus. It annoyed the hell out of some database programmers when a consultant told them they could apply OOP even to SQL.

The teaching process seems to work better if a "lead" consciously introduces some new concept or pattern (just one or two at a time) during a project, say, the design phase. That is, integrate the teaching into a project, instead of making it an independent event. People learn and use a pattern right away without their precious time taken away.

[adrianh]

There is, of course, another side to that coin.

There are also those developers who are determined not to learn. Whose approach to any new tool or practice is to find a way to rationalise not using it.

I know I'll be encountering people who have read the Perl patterns articles on O'Reilly and will be saying to me "I don't need patterns - look Perl has foreach" and completely missing everything else.

These people are not in a majority - but I bump into them more often that I'd like.