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.

During the last decade, the gap between the demand for new, complex software systems and its supply has widened. This gap and the difficulties faced by software engineers in bridging it have been described, some decades ago by Dijkstra as the Software Crisis: systems have become so large and complex that creating software for them is increasingly more difficult to complete on time and within the constraints of the project budget.

Software reuse is then of growing importance as a major factor in alleviating some of the problems resulting from the Software Crisis.

At first glance, software reuse appears a natural way to develop software, but in practice this does not happen. The challenges are numerous and require a fresh approach to the entire range of activities involved in the engineering of software. Every time new software is needed, developers tend to write it from scratch rather than harness components developed through previous projects.

In the first four decades of computer history the emphasis was on hardware developments, but now the emphasis has shifted toward human concerns. In the mid-1950’s, 90 percent of application costs were devoted to hardware but now, at least 90 percent of these costs are software. This reversal reflects not only the decline in hardware costs and the increase in programmer salaries, but also the recognition that systems must be carefully designed and developed to accommodate human users.

Software is essentially a symbolic product. It differs from the vast range of other products produced by conventional engineering techniques. Software, once designed, has no manufacturing phase and does not deteriorate, although changing environments will usually require software modifications.

The most often cited reasons why software is not reused are:

• lack of tools to support a developer in trying to reuse components
• lack of training for developers to create reusable components and to use reusable components
• lack of an educational methodology and motivation towards reuse and its benefits

The fact that software reuse has not been widely accepted questions the suitability of existing management practices, organizational structures and technologies involved in the development of software.

In short, a rethink of the software development process is long due.

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?