Ad Hoc and Systematic Reuse

In the software factories book, we explain that systematic reuse is effective, but ad hoc reuse is not.

Ad hoc reuse is the “Field of Dreams” approach… “If we build it, they will come”. Great line for a movie, but it doesn’t work well in the real world of software development.

Systematic reuse relies on the recognition that every component embodies many assumptions about functional requirements, technology choices, operational requirements, architecture, deployment topology, testing strategy, development process, and many other aspects of the software development life cycle.

Failing to recognize and plan around these assumptions leads to the well known problem called “architectural mismatch”. This problem is described in detail in a series of papers from David Garlan at Carnegie Mellon. The patterns and practices team arrived at this same conclusion “bottom up”, by listening to customer feedback regarding the guidance offerings they were developing. Customers were asking how to use those offerings to build a specific type of application.

Recognizing and planning around these assumptions leads to defining families of similar solutions, and separating their common features, which make them similar, from their variable features, which make one member of the family different from the next. The common features are used to develop a custom process for building the members of the family, and of a set of reusable assets supporting the process. The variable features are used to drive parameterization, configuration, assembly and other techniques for accommodating the differences between the family members.

This is the thinking underlying the development of the components that are truly reusable, such as RDBMSs and GUI frameworks, although it may not have been recognized at the time by all of the people involved in building those components.

Work at the Software Engineering Institute (SEI) formalized this thinking in the concept of Software Product Lines. Software Product Line practices have been well established through many books, case studies and experience reports, and are widely accepted in the software engineering community.

Software Factories is a methodology for using domain specific languages and other technologies to automate Software Product Lines. They were developed by leveraging the work of David Garlan, as described in the book, in consultation with the authors of Software Product Lines at the SEI, and with other experts in related disciplines, such as pattern languages, generative programming and feature based development.

Comments

• Anonymous
  October 19, 2006
  Now that I got my Feed Demon back, I actually have some stuff in the queue that is not so "new" but perhaps

• Anonymous
  October 25, 2006
  Jack, Have you folks given any thought to using LINQ in a DSL and if so, in what form?  In specific terms, I'm looking at the DSL Toolkit V.1 and trying to use it to create a software factory where an important portion of the functionality of my DSL is also covered by LINQ. Essentially I need to be able to query over my object model and then manipulate the model based on query results.  In a way, my DSL has a SQLish feel to it as it stands, but I need access to more than just persisent data.  Anyway, my feeling is that we can capture the systematic reuse aspects of things well in such a model, but I'm fuzzy on the tool use.  Any light you can shed would be appreciated. Van Simmons (yeah, that one.  :)  )

• Anonymous
  September 24, 2007
  Now that I got my Feed Demon back, I actually have some stuff in the queue that is not so "new"

• Anonymous
  December 03, 2008
  Now that I got my Feed Demon back, I actually have some stuff in the queue that is not so "new" but perhaps still "notable." Architecture/CAB/Smart Client Oldie but goodie: Eugenio has compiled a list of CAB and Smart Client Software