How would you use design patterns to educate and share design experiences?

Question

Hi all,

I work in an environment where scientists and programmers work together to create and maintain scientific simulation software. The software exists for 20+ years, and shows its C/procedural programming heritage, although the intent is to improve object orientation in the design.

The scientists have been involved in the development of the software for many years, and are used to procedural programming techniques rather than object oriented design techniques. They are not very educated nor very much interested in software engineering practices. The programmers are a mix of skilled, senior software engineers and scientifically educated programmers.

I would like to stimulate discussion about current design practices, and educate about the application of design patterns. I can give presentations, and ask other SW engineers to do the same, but since the group is quite large (approx 60 people) this will be the best way to stimulate discussions.

What are your experiences in using design patterns for stimulating education and discussion of design practices?

Answer 1

I think the first step would be to earn credibility by effectively working with their code following their existing practices. If you start to make their code OO without adding real value, or are just not able to work on their code because it doesn't suit your style, you won't have credibility and they won't listen.

The next step might be, as you make significant improvements to their code, introduce better design patterns. This would be leading be example. This method requires patience but is effective.

Answer 2

from what i've seen, design patterns only make sense to fairly experienced OO developers; design patterns presented to non-programmers or non-OO-programmers will probably kill them with boredom (death by PowerPoint) ;-)

better to show them how OO practices can improve the existing code base - but if it is straight C that's not going to be easy!

take a piece of the app(s) where the benefits of OOP are obvious and the effort required to make the transition is minimal (the "low-hanging fruit" approach) and do it, then make your presentation about how it was done, why, and how the principles involved may assist in improving other areas of the app(s). Adhere to the Scientific Method, and treat your presentation as an experiment, and measure the before/after results - the scientists ought to like that

this assumes that your instruction is desired and that you've already earned the respect of your peers in this organization; if you just joined the company last week - or last year - it may be a bit early to start evangelizing/mentoring. In that case it would be better to set an example and wait until they ask you how you did it

Answer 3

There's a ton of patterns in C-software, but the 'patterns' developed with Smalltalk in mind probably won't make that much sense.

The most basic pattern teached in introductory CS classes is the following:

input data
process data
output data

You can make ton's of apps cleanly by following that master-plan. Most discrete simulation applications, games and strategic simulations can also be patternized.

Forcing C to be OO, tends to turn everything into unreadable spaghetti-code with sluggish performance.

Before the OO hype, you had lots of good thinking around encapsulation and modularity. Use that as a basis for your work instead of the Patterns / OO related material.

Answer 4

I think focusing on OO is probably not the most constructive path. I'd start with just good procedural design -- using patterns to express them is a fine method -- and also focus on nuts and bolts implementation that is relevant to their problems. For example, I'd present them with information on how to avoid round-off errors, the limits of floating point representations, memory management, basic abstraction, coding practices that emphasize overall organization and readability of code.

See what the people need rather than presuming that OO and patterns are going to be the most useful tools for them...

Answer 5

Get the book "Fearless Change: Patterns for introducing new ideas" by Linda Rising and Mary Lynn Mans.

One pattern that comes to mind is "Brown Bag": invite a smaller group of people together around a brown bag lunch, to discuss a design pattern of interest.

Also check out a related collection of patterns known as "Knowledge Hydrant" by Joshua Kerievsky.

Both works draw on the experiences of pattern writing groups. As they show, patterns are a discipline applicable well beyond the often-quoted (and often-abused) OO design patterns. As others answers have mentioned, including procedural patterns in the discussion would make sense.

In fact, you might consider encouraging pattern writing workshops, as well. Conveniently, there is a pattern language describing these workshops. This could be a more effective approach, if your goal is to get people excited about design patterns, than lectures about design ideas "not invented here". As the work community discusses its own practices, chances are that it will also take an interest in what the best minds "out there" have come up with.