Incorporate design patterns into your apps

I've used design patterns for several years. They allow me to build software at a high level of abstraction than class by class. This helps me to more quickly design an application (less reinventing of the wheel) that is structurally sound (fewer bugs and easier to maintain.

I don't use patterns.
Why?
Because patterns used by themselves don't have the effect that Alexander intended when he wrote "A Pattern Language", "The Timeless Way of Building" and "The Oregon Experiment" almost 30 years ago.
Also, he has since moved on to generative sequencing as the way to create harmonious living environments.
Here's the thing. Patterns exist as facets of an entire pattern language, which contains many, many tightly interrelated patterns at several levels of scale. When you build a room, a house, a street, a town, a city, a region, using patterns from a complete, well thought out pattern language, for every part of the design, planning and construction process, you end up with an integrated whole that reflects the unity of the language itself. Without that unity and cohesion, and without using patterns for everything, all you have is a set of disjoint solutions to problems.
I don't want that. Software development isn't urban planning. It may be able to use the concept of pattern languages, but without the whole magilla, the benefit is only partial-you may be able to solve some common problems, but you're not going to end up with software that has the same sort of timelessness that is Alexander's goal.
Reuse, componentization and refactoring are better solutions right now.

I used to think of patterns as a cool, but generally not a very useful thing. After all I worked alone and I knew what I knew. They where either to general (up in the Duh range) or weirdly high level, in a way I cannot accurately describe. It seemed like a lot of trouble to go through. Then I became a development manager?..

I find that there are two things about accomplishing work. First are those people who have no idea how to solve a problem, they have an idea what they need to be doing, but no idea how to get started. Our pattern book allows me to give that direction to junior people, without doing it for them. Our patterns have two goals, a high level abstract, and some practical notes and a list off applications where we implemented the best examples. Second there are a dozen ways to do something, depending on the vendor of the technology, but frequently only 2 are acceptable implementations in our environment. The patterns in this case point you at the way to do things, here, not out in academia, or this other company.

Finally it gives us a way to document our coding standards without going down into the minutia of every possible outcome. The programmers are professionals, they get the idea from the abstract (one paragraph) and they understand the justification (again one paragraph) and they really like the fact that examples and projects using the pattern steer them to their solutions (old and new developers) It allows me to given them a self-empowering direction.

One side effect we have noticed in documenting this way is that when new technology implementations come around, ASP to ASP.Net for example, it?s these pattern sheets the R&D people work from to decide what to research, what examples to flesh out and what priority each technique has for research, the result is we rework the how to (the patterns are the same) and the justification and we are sure we have not missed or failed to address some aspect of the programmers reality on how to do things. Before the R&D group would get mixed reviews like ?that?s great but you should have? first? or ?Ok but you missed this and that?. Also our ISO reviews our techniques so that they understand possible security trade offs we have made as an enterprise.

From the purist standpoint this might not be what they had in mind as patterns go, and from the lone programmers standpoint, this level of documentation is not really necessary, and purely from a ?technique? point of view, very experienced programmers would not need them either. But get 50 programmers (all of them know the best way) of all sorts, 10 ISO and 3 managers in the mix looking for an organized solution and pattern documents sound pretty good.