Customer Reviews

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

5 star:		(6)
4 star:		(2)
3 star:		(3)
2 star:		(1)
1 star:		(0)

 

 

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.

Wow! I bought this book a long time ago and it lived on my "bibliophile" stack of bought but unread gems. It's a stunning book if you seek to understand the decomposition of complexity in modern software applications and the complex deployment architectures they work in. My only concern is the book is not an engineering book - there are no mathematical models of scale and performance for distributed decompositions. It has a excellent description of aspect oriented programming which I learned from. The authors could also benefit if they discovered the ideas in Carliss Baldwin's superlative "Design Rules" book and brought those ideas into their own discussion of the software construction domain. This is a WONDERFUL book for enterprise architects.

I have been following Domain Specific Languages (DSL) and model-driven development for some time. Software Factories (SF) seem to be one of the first development process framework that leverages DSLs. What I have expected from this book is to describe the relationship between the two.

The book does a very good job at describing the intentions behind DSLs (good job Steve and Stuart). The SF portion is less digestible. Often wordy, with long tedious lists of barely related facts. I feel the author wanted to cover as much of the field as possible. Still, I got lost several times in the details.

The formatting of the book does not help either. Please, use numbered sections! Many times, I did not know if this is a detail of previous section, or a completely new one.

Probably my major complaint is the missing link between the DSLs and SF. I just did not get it. Still, the book is very worth reading.

One of the biggest books I've recently read. And I would say that the preliminary analysis on software re-usability and quality is even more significant part than the idea of software factories (which is good one though). The necessity of DSL is demonstrated in a very straightforward way so that necessity of development on higher levels abstraction becomes evident.
Since the material is strongly consolidated, one would re-read the books several times each time finding something new to perceive. Authors are great guys - I would eagerly read any other book of their authorship.

With four authors the writing is a bit varied toward the middle to the end, but overall this book is just plain boring; I find this to be a fascinating subject and even I was bored. Go figure.

My main gripes about this book (boredom aside) are:

1) The coverage of DSL's (domain specific language): the authors repeatedly state that the cost of dsl developement can be prohibitive. I dispute this arugument as languages such as ocaml make the implementation of arbitrary languages realatively straight forward to people with the know how.

2) They claim domain specific languages are more powerful than general purpose languages. Their concept of 'power' seems to be skewed toward some weird metric I'm not familiar with.

3) The Microsoft bias is just annoying. Doubly annoying because if anything happens in this space it will be from the open source crowd, imho.

4) There's alot of repetition; every other page the authors are remaking the case for increasing abstraction in developement tools because 'compilers increase abstraction from assembler'. Okay, I got it the first time, you don't have to repeat it fifty times.

I think it's inevitable that something like software factories will emerge in time. This book gives an overview of the authors vision of where things are going. But they're academics writeing to an academic crowd and that's how the book reads.

This is an awesome book for an overview of the software development industry practices. It includes a detailed breakdown of product line engineering, as well as a ton of other great information.

VSTS 2005 missed the mark on Software Architecting Tools, and only includes System Architecting tools. With my own MSDN subscription I opted for the Developer version instead of the Architect version because of this. Microsoft is banking on the Software Architecture Tools of Domain Specific Languages (DSL) instead of UML and Software Factories (which Product Line Engineering is the heart of).

This is great except for the fact that to use it properly is going to cause a huge learning curve. Not so much with just DSL, but in applying the industry standards that exist in the architecture world to this new way of architecting. It is going to be hard to move software factories into most development communities. It will be great for engineering firms that take 3 to 5 years between releases, but in the type of environment that needs to consider time to market, software factories are going to be difficult to sell.

If you get this book, I suggest not getting to carried away with the software factory part of it. Software Factory information only takes up about 20% of the book. The rest is great material.

First, the Software Factories concept is great in some points while it combines model driven design and domain specific languages. If it is a real future for software development you have to read and take your conclusions.

But..this book is too Microsoft biased. As written by a MSFT emplyee this is kind of expected but the fact is that the guy makes everything to say C#/.Net is the future of Java. This includes saying that JIT compilation was first introduced by .Net, that JavaBeans are a convention that are evolved in C# by delegates and properties and lots of other tries to make people believe that .Net is an evolution of the Java platform. I think this really compromises the book and would be much, much better if it just used C# and forgot all comparisson.

I'd suggest that people intersted in MDA, DSL and new trends read this book but just skip all the Java bashing.

This book is interesting but it is poorly organized. It seems that ideas are mixed, and chapters repeat the same ideas again and again, sometimes calling them in different way.