http://qs321.pair.com?node_id=285070


in reply to Re: Design Patterns Still Aren't
in thread Design Patterns Still Aren't

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.

Replies are listed 'Best First'.
Re: Re: Re: Design Patterns Still Aren't
by chunlou (Curate) on Aug 20, 2003 at 07:25 UTC

    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.

      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.