In their book, “Patterns-Based Engineering – Successfully Delivering Solutions via Patterns”, Lee Ackerman and Celso Gonzalez introduce PBE, the concept of a pattern implementation as an asset that “automates the application of a pattern in a particular environment”:

Specifically, PBE is a specialized approach to asset-based development that focuses on patterns, a specific type of reusable asset. PBE provides guidance and support for using patterns in a systematic, disciplined, and quantifiable way.

You can use these types of patterns to support design, testing, deployment, and other aspects of the software development lifecycle. In performing these tasks, you use patterns in many ways such as documenting, generating, refactoring, and harvesting. As a result, you are able to use patterns to boost productivity, improve quality, leverage expertise, simplify, and improve communication within an organization. The goal is to ensure that as you use and create patterns, you are doing so in a way that adds value and boosts the agility of your projects.

Similarly, ABSE uses reusable patterns (a.k.a. “Atoms”) as the basis of its model-driven approach.

ABSE patterns are coupled with metadata, giving them the necessary variability to deal with real-world applications. ABSE Atoms have borrowed concepts from OOP like inheritance and composition, allowing you to create pattern families, and build “patterns of patterns”. Atoms are glued together like Lego to form a model that has a tree-like structure. A code generator “executes” the model to obtain the desired generated artifacts.

If you want to learn to use and apply ABSE, you may start by introducing yourself to the Patterns-Based Engineering approach. It will give you a thought process and logic foundation that will be quite useful to fully understand and take advantage of ABSE and its IDE, AtomWeaver.

To buy the book, contact the authors or if you are just plain curious about PBE, stop by the PBE site.

Software Craftsmanship is an alternative way of thinking about the activity of writing computer software and skill acquisition mechanisms. It is a growing movement amongst software developers dissatisfied by the mainstream software industry’s focus on the skill-level of the median programmer.

In December of 2008, a summit was held in Chicago that resulted in the drafting of the Software Craftsmanship Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration,but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Although we are using code generation more and more, shifting some responsibilities away from the average developer, we still need to keep crap code at bay. When we upgrade to model-driven development, we switch to the trade of keeping crap models at bay. A Software Craftmanship orientation is here to stay and we should embrace it.

In-house code generators help implement a Software Craftsmanship initiative by enforcing the use of correct and tried-and-tested designs and patterns.

Read more about Software Craftsmanship (books @ Amazon):

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman
Clean Code: A Handbook of Agile Software Craftsmanship
Software Craftsmanship: The New Imperative
The Craftsman

I’ve just signed the manifesto. Did you?

I’m sure it happens to you. As much as you try to guess in advance all the problems you may find during development, you’ll end up fighting some problem for hours. You think it over and over again. And again. A solution is nowhere to be found.

It happened to me several (too many) times. Most of the time, after much fight, I end up reaching a solution. But on a few occasions, something startling happened: After quitting, usually because time ran out that day, I return the other day and find a solution in five minutes or less! And a simple one. “So easy!… Why didn’t I think of that yesterday????”

I start to wonder how much time I wasted by not quitting to fight the problem.

So from now on I decided to have a new approach to problem-solving: If it starts to take too long to solve, I move on to something else, and leave it for tomorrow or the other day. And I advise you to do the same. You’ll end up saving time.

The reason for this quite surprising effect lies on the fact that when we have a problem, we set a series of reasoning “paths” that, unfortunately, lead us to the same “solution candidates” over and over again. At a certain point, we cannot deviate from those paths anymore. We become stuck, or run in circles.

If we leave the problem behind for some time, we have the chance to rebuild those reasoning paths again, hopefully in new directions. But don’t leave it for too long. That’s because there is always important information you must retain to be able to solve the problem. The longer you leave it, the harder it gets to get started again.

Knowing when to quit helps you save time solving problems. Think about it.