I hope this series to be a very simple and easy way for developers to get acquainted with ABSE, to know what it can do, and what they can accomplish with it. It won’t take you more than two minutes per day.

New post announcements will be added to ABSE/AtomWeaver’s twitter account, and the fact pages can be found inside the ABSE section of the community site.

I take the opportunity to invite those that want to learn about ABSE and follow its evolution, to join its official community at http://atomweaver.ning.com.

Let’s see some good (valid) points about DSL’s:

• It’s domain-specific (duh!)
• Encapsulates boring details
• Can increase abstraction to the next level

And other not so valid points:

• It’s a Shiny New [mainstream] Thing. Most developers love that
• It’s cool and I can do it too

The first are very enticing, valuable, and sought for, and most of DSL’s attraction I guess comes from these features. But, will it pay off?

I really don’t have much experience with DSLs, so I won’t use my own arguments. I’ll let the community speak for myself. Here is a tiny sample of DSL criticism:

http://c2.com/cgi/wiki?DomainSpecificLanguage

… the Tower Of Babel effect that results from having so many languages that a person needs to be familiar with (if not master) in order to get common jobs done.
…
writing a good DSL that is robust and reusable beyond a limited context, is a lot of work. It requires persons with both domain expertise and language design expertise (not necessarily the same person) to pull off. A truly reusable DSL will require reasonable documentation, otherwise it won’t survive the departure of its designers.

http://www.theserverside.com/news/thread.tss?thread_id=42078

The other mistake some folks make is they think that with a DSL that “non-coders” can actually use the DSL.

But since a DSL is designed for automation of an underlying objet model, writing in a DSL is just like writing in any language — whether it’s DOS .BAT files or Java, and it takes a coding mindset and understanding of the underlying domain as represented by the computer in order to make effective use.

There was much more written on this thread. You can go to the original page to read more opinions.

As general use of DSLs become mainstream, so become the complaints about their shortcomings. If we take so much time to master a general purpose language, should we invest a comparable amount of time in limited-use languages? How can we get support for a DSL, apart from its own creators? Where’s community support? What happens after the departure of the language’s creator? What’s BNF? Do I need it?

DSL critics say really useful DSLs are hard and expensive to create. DSL supporters answer that DSLs are not designed, they evolve. Well, won’t any of those “evolutionary steps” risk breaking the entire development based on that DSL, much like a broken app build? Will the evolution in the language be severe enough to trash what has been done so far? Can you imagine yourself developing a complex C++ software system while C++ itself was still being designed and developed?

Still too many unanswered questions.

OK, so the current website is a little short on details, but not short on propaganda ! That’s because the first task will be to evangelize the developer community and not to have the technology reviewed by industry experts. ABSE is still in its infancy, and a lot will evolve and change in the coming years. However, ABSE 1.0 will give you plenty of rope to play with (and hang yourself as some would say) and give you a glimpse of the future.

Some people in the software engineering community are now saying that model-driven software development will be mainstream in three years from now, and I am happy to be one of the visionaries that is working on that edge.

For now the ABSE website contains a lot of details about the methodology’s meta-metamodel, the Atom, and many application scenarios. I guess explaining a new philosophy to the crowds will require lots of tinkering with the message I want to pass on, so I’ll have to keep working on the site’s content improvement.

Also AtomWeaver is not far away. Participants in the Early Access Program will receive an alpha version in November, while a beta/CTP version is expected for January 2010.

The start of the coming decade will see a turning point in software engineering. I am happy to be contributing for that with ABSE and AtomWeaver.

People on the Early Access Program can have a first look at this new technology. In return I ask for some neutral feedback.

The first material to be available was a combined slide-style presentation of ABSE and AtomWeaver. The presentation gives a rather limited view of ABSE, and trying to understand ABSE through some slides is still a challenge at this point. However, feedback has been essentially positive, with some people having some doubts about its effectiveness due to their lack of understanding of ABSE’s mechanics.

Most feedback ranges from “promising” to “impressive”, which leaves me confident about ABSE’s official debut in Q1 2010. Stay tuned!

I’ve been for years researching ways to develop software in a way that I would be more productive, more organized, more effective. After a first attempt in 2000-2001, and with limited, isolated ideas for a couple of years, a “click” came around 2005 that took me on a trip to a new way of thinking about software development.

I was thinking of a more declarative way to do things. I was thinking in not doing the same things over and over again. I was thinking of transforming my development experience into an automated library. Essentially, I wanted to duplicate myself. I wanted to have the work strength of a small team.

This was the initial rationale behind the development of ABSE. I wanted to have a model of my software project and then, by the switch of some buttons, I would be able to change code, and this code would adjust itself to the specification I ordered. And things could be specified at an unlimited higher- or lower-level. A project would be made of some or millions of small things… and the ABSE Atom was born.

ABSE first evolved as CodeGen4, a simple string-substitution template-based system. Then I thought it would be much powerful if each Atom could be a program in itself. This way the model could “think” according to the specification. Cool! Many new things could now be done.

In January 2007 I started building an IDE that would help me fulfill this dream of mine. A few months later I abandoned the IDE’s development and started again. But this time I wanted to do it right: The IDE should be built using an ABSE model! But how? I didn’t have a tool to build an ABSE model… So I used Leo, a scriptable outline editor. After many hours building scripts and auxiliary tools, I was able to develop AtomWeaver, an IDE that implements ABSE, using ABSE!

I knew that many hours would be spent developing code and scripts that would be thrown to the electronic dumpster once AtomWeaver would become usable. But software development is sometimes like that: you must give one step backward so that you can give two steps forward.

ABSE and AtomWeaver are currently being polished to a point that they can be understood, used, supported, (and I hope) loved by the community. The initial release is near. Stay tuned!

I’ve started research on this subject around 2000. In 2006, I’ve finally developed a generic modeling methodology that I labelled ABSE (Atom-Based Software Engineering).

What could be the most curious aspect of ABSE is that it was developed isolated from the global MDSD circles: I’ve learned about stuff like DSLs, DSM, DDD, Sofware Product Lines and Software Factories *after* I devised ABSE. So ABSE is probably unlike what you have seen so far in the MDSD scene (whether that is good or bad remains to be seen).

For now, ABSE has its home, at www.abse.info. Keep watching that space for new developments that will happen in the next months!

At the same time, I found the “960 Grid System“, a kind of “CSS Framework” that lets you easily create a homogeneous design through columns. It’s also good for prototyping.

The 960 Grid System is free to use, and may be adapted to meet your specific needs. Several projects have already spun off, including versions that were built to be fluid and elastic.

Check out a tutorial of the 960 Grid System, written by Adam Hawkins.

You can easily create a grid system using an online tool, at The Grid System Generator where you can simulate some designs. The site itself was built upon the grid system and looks great!

It’s no match to a good designer, and to use this system you still need to apply some design work and some good taste, but for those that want a simple and good looking solution, I hope this helps.

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?

Like any other engineering discipline, software engineering can gain a lot from a solid discipline of reuse. But unlike other engineering disciplines, software asset reuse does not come naturally in software engineering. When it does, it never comes without costs and risks.

Possible reusable asset categories:
- Requirements / Specifications
- Documentation
- Designs
- Architectures
- Source Code
- Test Data
- Executable Code

Software asset reuse starts by being a cultural thing. Managerial aspects play a critical role in it. Software asset reuse cannot happen without strong commitment from the managerial structure of the development organization.

Reuse Libraries and DSM (Domain-Specific Modeling)

We can consider two types of reuse libraries: Horizontal and Vertical.

An horizontal library augments the expressive power of the language without commiting to a specific application domain. It has the advantage of being useful across several projects, but it is limited to around 20% of the application’s total code.

A vertical library contains domain-specific components, and can reduce the amount of coding we need to produce by up to 65%. The drawback is that it can only be used within a single application domain, and hence potentially few projects

If we map these two types of libraries to the DSM paradign, we can say that an horizontal library lies on the solution domain, and a vertical library lies on the problem domain.

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.