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.

Comments (4)

  1. Wojciech Gebczyk says:

    I would say, teach patterns and at the end say that before you start implementing pattern(s) look around and check if there exists implementation that satisfies you.

    Why? If you first teach patterns then "student" can make 2 things:

    – not use it for real work. he is happy with current way and nothing will change his/her mind

    – decide to implement/use it – means that some physical (if code can be physical) component should be available to use in real scenario.

    So advice on tool search can only help this person avoid building from scratch desired effect.

    Additionally, patterns are language (person2person communication) – can "compress" a lot of words to describe something. It matters very much in context of "code" maintainability – using less words you can explain another person how it works. As you mentioned, "transferable knowledge" is just another description for very specific communication language.

    Unfortunately I cannot quote any good analogy for this language part as fishing 🙂

  2. RobL says:

    Whilst I completely agree with the post, I think you might need to address what the "tools" are attempting to provide. Apart from the whole consistency, compatibility etc they allow, they also make it easy.

    Although a lot of people may be aware of design patterns, maybe even have read the GoF, there’s a good chance they won’t follow them. Providing them with an easy to implement tool at least allows them to (potentially) create good pattern based projects without really knowing the how’s and whys. And you never know it might encourage them to learn the patterns behind the tool.

    Another great benefit of the tools is the example they provide. Many programmers I know can grasp the concepts of design patterns, but it’s not until they actually see them properly implemented that they have that "Ah Ha!" moment where they truly understand what and how the pattern solves something.

    So for a capable developer, learn the patterns first. No questions about it. Then, if required, dive into the tools to see real world implementations.

    For less capable developers (or even developers with less time/motivation), use the tools. It’s better than nothing. But ultimately, you’re going to need to learn and understand the patterns to benefit.

  3. Vaithees Kumar says:

    Yeah, you are right.  

    The tools are utlizable to the extend, where it be the starting point.  In the end, it’s the developer’ know-how of patterns going to make the the design sustainable and elegant. At another level the tooling makes the developer understand the design patterns.

    But as the tooling evolves – like in the DSL languages – could it mean in near future programmers don’t have to overly concern themselves about most of the design decisions, as configurable and usecase based recipes will do the job for them?

    BTW, Composite WPF – sounds interesting, care to post more!

  4. I am VERY excited about this direction!!!!!!  I am looking forward to the P&P as much as the features/tools coming down the pipeline.

    From the trenches – I can tell you that not knowing how to use a powerful tool is a very dangerous thing… Particularly for new contractors/employees who have varying levels of knowledge, are given the keys to the source safe and let loose to knock out the issues and requirements.  

    I once worked a project that had over 10,000 lines of code in the main form – the early team that converted the legacy C code over to the Microsoft platform did not understand OOP and more importantly the .NET Event Pattern.  In their environment they were guru gods and the fact that they got the application to work as they did just showed how brilliant they were.

    Our team came in and upgraded the application to .Net 2.0 and got it to production against all odds.  Unfortunately we spent 80 percent of our time debugging the UI, 10% refactoring what we deemed critical (so it could be maintained once in production) and the remaining 10% completing issues.

    If the early team had just spent a few weeks learning the event pattern and basic principals of OOP the second team would have never been required and it would have made it to production a year earlier..

    Had they used the Smart Client Software Factory I believe this early team would have used the applicable recipes to generate the modules and views and then commence to placing all of the code into the views.

    The steep learning curve is not with CAB or the SCSF – I can tell you first hand that it is with OOP, MVC (CAB) and MVP (SCSF).  Not to mention Generics and LINQ (which is awesome! although I think they should have called it Visual Foxpro 😉

Skip to main content