Patterns, it’s about teaching people how to fish

351022855_ebbb37749d_b[1]

Today 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.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.tobinharris.com/blog Tobin Harris

    Hi Glenn. Nice post, and I also completely agree.

    It reminds me of when we were taught relational database modeling and normalisation theory at university. When I actually started working with databases in the field, I found I prior knowledge of what I was trying to achieve and what capabilities to look for. So the learning curve for any particular DBMS became focused mostly on syntax and understanding particular nuances rather than the underlying principles which I already had.

    I guess the same goes for patterns; knowing them gives you high-level solutions to problems, and the learning curve becomes focused on figuring out how to apply them elegantly in any given language.

  • http://lazycoder.com Scott

    I completely agree Glenn. In fact, I think that learning the reality underneath the abstraction applies to the platform in general.

    http://www.lazycoder.com/weblog/index.php/archives/2005/04/26/bad-developers-are-made-not-learned/

    It’s not that you can’t be a competent, “good”, programmer that solves peoples problems if you can’t lovingly handcraft assembly code, but understanding how computers work, how GC works, how hard drive I/O works, makes it easier to diagnose problems and design systems.