Patterns, it's about teaching people how to fish

The other day Larry Brader (Our Lead Test Manager) and I were having an interesting conversation that led me to make the above statement. Larry and I were discussing the root drivers for many of the architectural qualities I have been pushing on within the "Prism" project. This includes qualities such as Simplicity, Subsetability (no I did not make this word up) and Compatibility. As I began to explain, I quickly started working back historically, until I ended up right back at Jeremy's "Build your own CAB" series and the great "CAB" bash that ensued from his initial talk at DevTeach.

The crux of Jeremy's argument was that if it's a choice between learning patterns or learning to use a tool that implements those patterns (CAB) then he would choose to learn the patterns. It may surprise you, but I agree completely (though not everyone agrees). The second part is that if you are going to use a tool, then knowing the underlying patterns behind the tool means you are more effective in the use of that tool and also gives cross transferable knowledge that you can use either in the absence of a tool, or apply to a different tool.

In Software Development we know that the one thing that is constant is change. Some things may stay the same, but as we make new discoveries at the hardware, software language, and methodology level, change occurs. Just about 60 years ago software development was limited to an elite few who developed software inscribed on Hollerith cards. The tools you use today will not be the tools you use tomorrow. Take languages for example. My first exposure to computing was Basic on a Commodore Vic-20. Since then I have learned several variations of Basic (at least 5 I can think of), Logo, Fortran, Pascal, A few flavors of Assembler, C, C++, Javascript, PHP, Java, C#, and now Ruby.

What's common about all these languages? It's the behavior those languages encapsulate which can be expressed in pseudo code. Quite simply (and this is an oversimplification), it's Input, Process and Output. This I would argue is another constant that won't change. At the end of the day every programming language needs to support this. As I said this is an oversimplification in that there's a ton of sub-behaviors that you could put under each of the three. However, even at that level you will can find a common set that pervades all languages. In essence these are patterns of languages. Once I understand these patterns that means I can learn any language. The semantics (implementation) of the language continually changes, but the patterns stay the same

It's the same with software design patterns. Take the Factory pattern for example. At an implementation level the Factories of today are very different than the factories that were created back when the gang-of-four first coined them, however they still are factories. If twenty years ago all I learned was how to use the OldLanguageFactory then that doesn't necessarily help me use the NewLanguageFactory of today. I may not have even understood that the OldLanguageFactory is in fact a factory. However if I understand the factory pattern, then I can use that transferable knowledge to use the NewLanguageFactory. I'm also able to build a NewLanguageFactory if one doesn't exist. The same argument can be applied when looking at the CAB. CAB at it's essence is an implementation of a set of patterns including Dependency Injection, Builder, Composite, Command, PubSub, etc. If you understand the underlying patterns then you have transferable knowledge that will have benefits that transcend the current tools.

In the Web Client Software Factory, it is this rationale that drove the MVP Bundle. Since I joined p&p, I heard countless feedback from customers who did not understand how to properly implement MVP. Having the automated recipes that generated the presenter, view, and view interface and wired everything together was not enough. It's like great you did that for me, but now what do I do? So in the MVP bundle, we decided to focus on the pattern itself and then show you how you can implement MVP yourself without having an dependencies on the CWAB (Composite Web Application Block). We then showed you additionally how using the CWAB aids you in implementing MVP. Having that understanding of MVP means you can take that knowledge and implement it yourself, look at other alternatives besides CWAB that might aid you or use CWAB. It's really up to you.

Back to the fishing metaphor. Think of the patterns as you would think of knowing how to fish. Then think of CAB, CWAB, Prism is different kinds of fishing poles. Think of the challenges you are addressing in your apps as the fish. If all you learn is how to use one fishing pole, then that's not very useful. Having a knowledge of fishing means you are free to choose the pole of your choice, or create your own ;-)

In the new "Prism" work you are going to see us driving seriously on the underlying patterns for building Composite WPF applications rather than just reusable code libraries. Yes we'll give you a fishing pole (though it may not be the right pole for catching every kind of fish) but we'll show you how to fish first.