In the aftermath of Katrina, I have been in contact with many developers and hiring managers throughout the world. In my dealings I have come upon a new perspective of modern software development particularly in the Microsoft .NET areas, although it applies to any object oriented environment. Please excuse my English as it is a second language behind C# at this point.
The particular comment which I have heard numerous times from senior level people is, "We do not create large enough systems to benefit from design patterns". This comment shows a complete lack of understanding of what design patterns are. To think of a system that could not benefit from design patterns I must resort to a "Hello World" program! I have also heard the comment "We would like to use design patterns but do not have the time given our environment" numerous times. Perhaps it had been my isolation in the technology backwaters of New Orleans but I've been under the impression that design patterns are heavily used through out the industry to ease communication between developers and to provide more cohesive systems to lower the learning curve for new developers.
Design patterns are elegant, well tested, and most importantly reusable solutions to recurring problems in software design. By understanding them you can quickly discuss complex architectures with other develpers and more importantly, you can provide a cohesiveness to your code base which allows a faster ramp up for new developers brought onto a project. An example of a design pattern can be seen in any asynchronous operation in the .NET framework. You may have already noticed that they all operate in the exact same way, due to Microsoft's use of the Async Pattern in the framework itself. Needless to say, once you learn the async pattern you can not only use any of the framework objects that support it easily, but you can also implement in your own objects and a developer who has never seen your objects before will understand exactly how to use them. This is in and of itself the benefit of a design pattern, because it is generalized knowledge.
The concept of knowledge is often represented using the metaphor of building blocks; you use the building blocks that you already have and extend or manipulate them to provide a new piece of knowledge which will eventually be used as a building block for yet another innovation. Whenever a new building block is added there should necesarily be a period of innovation after as it is applied in new and/or different ways. Can you imagine if every physicist had to derive all of Newton's work on his own as opposed to learning it? Once a developer is given the building blocks contained within the most common design patterns there tends to be a "code rennaisance" shortly after, where their newly written code completely transforms. For those supervising managers reading this there also tends to be an extended period of refactoring previously written code to make it simpler, more flexible, and of course more maintainable.
Continuing with the "Building Blocks of Knowledge" metaphor: One can picture these building blocks stacked upon one another with the core blocks being at the bottom and derived blocks being laid upon them, so your core blocks are your most general blocks while more specific blocks of knowledge are derived from them. Based upon this one logically concludes that new building blocks introduced close to the bottom of the stack would intrinsically create further innovation compared to those introduced towards the top of the stack, as the lower blocks would have more blocks they could feasibly interact with. Based upon this one concludes that when it comes to educational returns it is best to focus upon more general items as the more general items will cause larger amounts of innovation within the knowledge space.
While also providing this larger base, the creation of these less granular items has the side benefit of removing core blocks which are in error. Since these are core blocks removing them will cause the derived blocks to be invalidated, thus removing many bad habits at a single point. Since design patterns are generalized to exist outside of any language one can validate that they are indeed a very generalized block of knowledge and will therefore show further gains than other educational works in more granular areas.
Although this explanation is fairly complex (bordering on philosophy) a real life argument can also be put forward. A supervisor who has subscribed to any of the modern development methodologies (i.e. RAD, XP, etc.) knows that the key to a successful real world implementation of any methodology is the ability to re-use code. That means that an expense associated with training your staff to create more re-usable code will show an immediate benefit to your bottom line in future projects as there will be less code to write. Due to this and to the fact that conceptual building blocks are always on a lower level than implementational building blocks it becomes obvious that an educational budget will give a far better return by teaching your developers the concepts of design patterns as opposed to the newest seminar on the whiz-bang component or development tool as the concepts learned through design patterns are language and platform independent.
Resources for further learning:
Online
http://msdn.microsoft.com/practices/
http://www.dofactory.com/Patterns/Patterns.aspx
http://www.codeproject.com/csharp/csdespat_1.asp (series of articles illustrating GoF patterns in C#)
http://www.martinfowler.com/
http://hillside.net/patterns/
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/ (old link but rather useful)
http://www.artima.com/lejava/articles/gammadp.html
http://www.xmlpatterns.com/ (patterns and XML)
Books
Design Patterns, Elements of Reusable Object-Oriented Software, Erich Gamma et al. (classic work also known as GoF)
Pattern Oriented Software Architecture, Volume 1, A System of Patterns, Frank Buschmann, et al.
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects, Douglas Schmidt, et al.
Pattern Oriented Analysis and Design: Composing Patterns to Design Software Systems, Sherif M. Yacoub, et al.
Enterprise Solution Patterns Using Microsoft .Net: Version 2.0 : Patterns & Practices, Microsoft Corporation
.NET Concurrency Design Patterns: Programming in C#, William Stamatakis
Agile Principles, Patterns, and Practices of C# and VB.Net, Robert C. Martin, Micah Martin
Patterns of Enterprise Application Architecture, Martin Fowler et al.
Summits
Microsoft Patterns and Practices Summit