Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools [Paperback]

30 second summary of the book:

- Software development is awfully inefficient. Most of the applications we write have more similarities than differences, yet we build every project from the ground up.

- UML is great for communicating on a white board but fails with respect to bridging the gap between requirements and code. The limitations of present-day CASE tools shows this inefficiency.

- Innovations such as the maturation of domain-specific languages (DSL), at varying levels of abstraction, and the support of these languages through IDEs are needed to make the next step in software development.

- These innovations will provide the key to creating product lines built on reusable processes and software frameworks: software factories. The adoption of this approach will lead to automated development, faster delivery time, systematic reuse, less testing, and greater maintainability.

5 second summary of the book:

Microsoft Visual Studio 2005 Team System is going to be really really cool.

The good:

Greenfield gives a very thorough (600 pg) introduction to the software factories approach to solution development. He presents a convincing case describing current deficiencies in the world of software development, how domain-specific languages and more advanced IDEs will correct these deficiencies, and what challenges remain between us and realizing the goal of having a true software factory.

The bad:

This book should not be seen as a technical how-to book. Do not expect to be able to apply much of what he describes within your software development routine...unless, of course, you're designing a next generation IDE. This book takes a more academic approach to describing the theory behind software factories. In the near future, when Visual Studio 2005 Beta 2 is available, Chapter 16, "A Software Factory Example," may become useful as a reference as it presents a good example of applying the approach to the project life-cycle. But until then, the material is not very practical, due to the fact that no IDE currently supports the ideas that he has presented. But even after Visual Studio 2005 becomes available, you probably won't open this book too much after the first read through.

The hype:

There has been a lot of buzz online surrounding the software factories approach to development. Once we're able to try out the approach within VS 2005 Team System, we'll all be able to decide if this is going to be the next wave of development or just another neat idea. As for me, Greenfield has me convinced that this is certainly a step in the right direction.

The authors present a massive and sophisticated approach to understanding and integrating patterns, models and frameworks into a project. The tone is scholarly, with many references to important previous papers and texts. The book is targeted at developers and senior programmers. Much of it deals with the different levels of abstraction, and how you move between these. So that if you have designed a project using patterns, then this is a high level structure. The book offers aid in migrating this into a framework, which might be considered a reification of the patterns.

An extensive survey is also given of various design/modelling tools that are available. These might be open source, proprietary or of the academic research type. One easy thing you can do with this book is to use its analysis of these tools. This is doable without having to wade through most of the rest of the book.

The book will not be an easy read to some. A lot of material is covered and a considerable amount is fairly abstract. Without significant prior experience in design and coding, you may miss the full meanings and appreciation of much of the text.

It makes a typical computer book look trivial.

This book in my mind represents the state of the art in software engineering today. The book is based upon the concept of building families of similar, but distinct products, which have been around for years in other engineering disciplines such as civil, mechanical and electronics engineering. These concepts promote the systematic reuse of like components and factored out variable components for customization in order to produce products that were similar but yet each one being unique. This is commonly known as mass customization, something that is very new to the software world, but "old hat" for other industrialized engineering industries.

I know Software Factories is an overloaded term, but consider this definition: "a factory is a highly organized production facility that produces members of a product line using standardized parts, tools and production processes." The "factory" term is common in the industrialized engineering world, but extremely uncommon in our un-industrialized software development world.

Jack and Keith initially introduce us to dealing with complexity and change, which are the two fundamental problems in designing and constructing quality software of any size. Anyone that has read the Standish Group's CHAOS report understands our incredibly poor track record in dealing with these fundamental problems, regardless of programming languages, platforms or methodologies used. The following chapter on Paradigm Shift assists the reader in understanding these problems as well as the critical innovations that solves these problems.

Software Factories goes on to explain their concept of what is a Software Factory within the context of economies of scale and scope. This is the most critical point of the book to understand, "Economies of scale arise in production, while economies of scope arise in development. Economies of scale arise when multiple identical instances of a single design are produced collectively. Economies of scope arise when multiple similar but distinct designs and prototypes are produced collectively rather than individually." This fundamental concept is absolutely key in understanding the how Software Factories pave the road to the industrialization of software. The authors could have spent more time on this subject at it is the most confusing concept for any software or non-software person to understand and represents the barrier to understanding that software development is no different than any other traditional engineering development process.

The next 3 chapters delve into Models and Patterns, Programming with Models and Language Anatomy and how these approaches raise the level of abstraction so that models can be used as first class development artifacts. Essentially how Domain Specific Languages (as opposed to general purpose languages) converges the gap between requirements (problem input) and executables (the solution).

The following 7 chapters cover in detail the concepts above by discussing Families of Languages, Systematic Reuse, Software Product Lines, Platform-Based Abstractions, Components and Services, Mappings and Transformations, and Generating Implementations. Incredibly well done and I cannot do these chapters justice in this short review.

Chapter 16 demonstrates a concrete example of a Software Factory using all of the concepts, techniques and best practices described previously in the book. Jack and Keith "show how the methodology can be implemented now, that it can be widely used to complement and eventually replace existing practices, and that it can help move the software industry toward maturity." This chapter alone is worth the price of the book.

Finally, a section on Frequently Asked Questions compares Software Factory approach to what we know about software development, before Software Factories. This puts into great perspective the differences between Software Factories and the current state of the art, which is commonly referred to as custom "one-off" software development.

I cannot recommend this book highly enough. As someone who came from the R&D electronics world 20 years ago where I (and the rest of the electronics industry) routinely used product line engineering development practices, I thought when I joined the software world 15 years ago this approach would be the norm. How naïve was I. This book should not only be required reading for anyone practicing software development, but also mandatory reading in every Computer Science program. Then maybe we will see the industrialization of software development become common practice as it currently is in other industrialized engineering disciplines.