Software Design Patterns for Parallelization

Welcome back,

it's been some time, but it's been some quality time:

In the last few weeks I've further investigated how to cope with the multicore era as a software engineer.
For this purpose I've collected software patterns, that can be used for code refactorings. For now I can say, that I see a huge benefit of using well-structured source code in sequential code when preparing to go parallel.

So I thought It would be nice to say something about those patterns:
In our lectures on software engineering we tell our students, that the usage of design patterns together with architectural pattern relatively early in the design phase has some huge advantages within the software development cycle. The benefits of these "solutions to recurring problems" called patterns are :

- With every developer having a sound understanding of patterns, the code is much more easily readable and will thus be understood much better.
- Patterns improve the team communication by defining a clear terminology for this specific context.
- Patterns improve both the quality and the structure of source code.
- With patterns, code refactorings like minor or even major revision updates for that software can be achieved much faster
- Patterns support state-of-the-art programming

But patterns also have one tiny, itsy-bitsy drawback:
- Nobody uses them. Ever.

Snap! OK, well...that's a bit too gloomy and pessimistic.But still: Design patterns in software are by far not that frequent, as they should be when you look at the benefits you get. Now, why is that so? One reason for sure is, that not many developers around the globe know about the full potential of software patterns. Within the last few years though, MVC (Model-View-Controller) was one pattern, which finally got some attention due to the strong increase in web applications. The second reason is, that when you don't know what you're doing you can experience problems with patterns you wouldn't have had if you hadn't used patterns. Of course it's not specific for patterns that you can mess things up, when you don't know what you're doing. Nonetheless does this keep people away from  patterns... The third reason - maybe the easiest to understand and the hardest to figth against: People do things the way they always did. Design patterns came up in the 1980s and gained some reputation in object-oriented design in the 1990s. Only since the turn of the new millennium are patterns a topic for research in software engineering. So, to many developers this still is relatively new. They didn't grow up with that paradigm and they clearly didn't learn how to program in such a way.

Now, I'm not here today to tell you, that the points of criticism to patterns are invalid. But when you take the time and read about software patterns and use them later on in one of the next projects, you will definitely appreciate the benefits mentioned above because they suddenly come reasonable to you.

When I find the time, I'll come up with a post on Intel's "Parallel Studio 2011" which is currently in beta. It's supposed to help the developer by guiding him through the whole process of parallelizing software.
I'll symbolize the results we got out of the first two real-world projects with a quote from Albert Einstein, who said:
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
K!

[1] - Model-View-Controller pattern (MVC): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[2] - Design Patterns: http://en.wikipedia.org/wiki/Design_pattern_(computer_science)