Happy New Year!

It’s now 2012 and it’s time to put ABSE and AtomWeaver on the map. On the model-driven development map, that is. 2012 will be the real dissemination year for the ABSE approach and the AtomWeaver IDE. The take-off year. Well, it should be…

This year, and for the first time, I’ll be attending the Code Generation Conference (CG2012) in Cambridge, the most important European event in this area. As of today, it’s guaranteed that I will be participating in the 2nd Language Workbench Challenge (LWC) to be held the day before the conference (March 27).

I’ve also submitted three speaker proposals for the conference. The accepted speaker results are not out yet, so the presence of ABSE/AtomWeaver could be extended beyond the LWC.

The Language Workbench Challenge was created to compare the strengths and weaknesses of modeling/language workbenches, based on solutions for a predefined set of cases. These cases are accessible to everyone, on the LWC web site.

See you at CG2012!

I’ve been aware for some years now of the “Lego Hypothesis”, a software engineering “dream” conceived by James Noble, Professor of Computer Science and Software Engineering at Victoria University of Wellington, New Zealand.

For decades, software engineering has “dreamed an impossible dream”, to build software as easily as building Lego houses, says James.

There’s a talk by James Noble on InfoQ about this subject. In this talk, James Noble imagines a world where the dream has been realized, where software parts can be found in worldwide repositories, where most software is built by reusing existing software, and where we’ve “finally been freed from the mundane necessity of programming”.

Of course, it’s a dream but, how close (or how far) are we from such dream? I, for one, have certainly been working in that direction with ABSE:

ABSE allows you to create the building blocks of your software systems that, though simple constraint mechanisms, allow you to build your software by snapping them together, just like Lego.

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.

This is it! AtomWeaver reaches its first “official” release, the desired “1.0″ label. For many, “1.0″ means immature, but for its creators, it usually means yay! I made it!… Yep, it’s that feeling.

AtomWeaver 1.0 is the materialization of an idea I had 10 years ago: Why not creating patterns of my own development skills, so that I don’t have to repeat myself over and over? At that time, I knew nothing about model-driven development, although I have already built a small code generator ten years before that.

This idea kept coming and going over the last decade when finally I decided that I had enough ideas to try and build a “variable-driven” code generator. Three and a half years later, and after three iterations of the ABSE concept, the whole decade-long project faces the outside world.

It has been a long journey. Still, I’ve just reached the “10%” milestone. My vision for ABSE and AtomWeaver is much larger. Version 1.0 is really just the tip of the iceberg.

It has been quite a long journey… so many headaches, so much fun!

I’ve started a few days ago the ABSE/AtomWeaver Early Access Program, a closed alpha test of the AtomWeaver IDE, where a select few professionals participate. More than twenty professionals and two tech reporters have been selected.

The objective of the Early Access Program is to get valuable early feedback from professionals that are actively engaged in Model-Driven Software Generation, or code generation in general. With this controlled alpha release, AtomWeaver has seen the real world, and real developers are putting their hands on this new approach to software development.

While most people have yet to report back, some justifying to be severely constrained by their current work, I am starting to get reactions on their first “impact” with ABSE.

I’ve yet to receive a neutral or negative comment about ABSE, which is encouraging. First reactions have been positive, with adjectives varying from “interesting” to “promising”.

I am also learning a lot about how to properly convey the ideas and philosophy behind ABSE, in terms of documentation and tutorials. As with any new, disruptive technology, newcomers always feel confused about the new concepts, and hardly know where to start or where to go. It is a challenging task to put ourselves in the shoes of a newcomer when we are precisely on the opposite side of the knowledge scale. This is called “the curse of knowledge“.