Customer Reviews

Software Product Lines: Practices and Patterns

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

 

 

Book compiled from numerous interviews as opposed to real practitioners. I've worked with product lines and was quite excited when this book was published. However, I was rather disappointed. It doesn't really provide the insight into how do I sit down and create a product line.

The first chapter is a great introduction to product lines. The next couple of chapters are okay, but rather fluffy. The rest of the book is really academic and formal and I didn't find it particularly useful. These chapters were also very difficult to read (tedious and dry). Too much pontification; too little real information.

This is the leading authority on Product Line Engineering (PLE). No other book comes close. This book breaks down the three PLE practice areas of Software Engineering, Technical Management, and Organizational Management and describes each in great detail. The book provides guidelines on each area and how to achieve institutionalization of your PLE process.

The book has a great patterns catalog, Software Product Line Practice Patterns. The catalog includes The Essentials Coverage pattern, Each Asset pattern, Build pattern, Product Parts pattern, Assembly Line pattern, Monitor pattern, Product Builder pattern, Cold Start pattern, In Motion pattern, Process pattern, and Factory pattern.

If you are involved with Product Line Engineering or Software Factories at all, this is a must have. You cannot do without it. If you aren't involved with Product Line Engineering or Software Factories, this is still a great read because it covers a process that should be implemented on every project. Implementing PLE makes a project reusable, predictable, maintainable, and manageable. Overall it adds measurable metrics to all the assets of a project.

Imagine! you are a well founded software engineer and try to establish
the product line approach in your company.
Imagine! managers ask you to proof that the product line approach will
have a "good" return of investment.
Imagine! you open page XXX in your book YYY and start reading section
ZZZ.
Imagine! you develop a concept for a business case in 2 hours though you
haven't attended any business class ever.
Surprise! the you is me
Surprise! the XXX is 365
Surprise! YYY is Linda's and Paul's Product Line Book (Software Product
Lines: Practices and Patterns)
Surprise! ZZZ is the "What to build PATTERN".

The Product Line Patterns are the heart and the most condensed
experience of the SEI Software Product Line Framework. Though most
people do not recognize the patterns give you the balance between too
specific and too general process descriptions. The three cycles Core
Asset Development, Product Development, and Management of the framework
are good for simple overview purpose and therefore appropriate for the
management level. The 29 practice areas guide you through activities and
methods; therefore they are basically at the operational especially the
engineering level.

But it is the patterns that help you to sail though some of the practice
areas to achieve a certain goal. The patterns set the process and the
workflow. They are different for different problems and environments;
that's what a workflow should be.
Hunting for the world wide valid process description that is specific
enough to be meaningful is like trying to invent the perpetum mobile.

Suggesting only one product line process would therefore mean that it is
very general or that it is valid only for certain organizations,
markets, goals, products, and people. The patterns are specific
processes that help to achieve only certain goals in a predefined
environment. Though I think the framework patterns can be improved and
extended they are much more meaningful to the product line community
than any other product line process description I have seen up to now.

So, if you've already made the decision to go with software product lines, this is an excellent book. It's got a huge amount of reference material, is well-edited, and clearly has the benefit of a lot of practical experience.

Unfortunately, if you're debating with or just want to learn about software product lines, this book isn't for you. I didn't see a single example of when software product lines are *not* appropriate for a set of work that needs to be done and, in general, this just assumes that you already have the sort of work that fits this model and dives right into the details. Also, the "29 practices" are spread over just under 300 pages, and make it hard to understand the big picture. It would've been nice to see even one-page descriptions of the patterns in context to be able to pull it all together more easily.

If you have the concept of software product lines down, this is a great book, but if not you can easily get lost or confused, so it becomes difficult reading. If you want to explore software product lines, buy this book, then while you are waiting for the book to arrive read the website http://www.softwareproductlines.com to get up to speed on the concepts.

Software product lines will become a must whether you develop enterprise software or embedded software. This is so much more than we ever discussed about software resue.....

This book is a wonderful compilation of academic and real world, practical views/implementations of software product lines. It's also a wonderful text to read just to ensure you have your current perspectives aligned with your overall goals (from base development & test all the way to C-level management of an organization).

In an answer to a criticism of the book:

Sure, the book does not go into detail about how to create a software product line... however, the book does mention WHY they excluded it: it is different on a line-by-line basis and, even then, on a company-by-company basis. You need to tailer such processes to fit your business strategies and goals and cannot begin development of a product line until you have some business objectives, etc. established. Sure, they drive each other, but many other things must be in place (as the book mentions) before you can start work on the actual product line. Once you have these things in place, your product line planning/creation should become relatively transparent.

The academic examples/views are presented in base essay form with wonderful usage of references and insight into the comments made. The practical, real-world examples/views are provided in a side-bar format that allows you to easily absorb and see application of what you just read in an actual business realm.

This book will get you thinking about any projects you are currently working on, future project and just how you perceive things in general. Sure, software/code reuse is important; but to what point can that be applied to an actual product line? Where do you start drawing lines? Where do you draw lines for general goals? What business management aspects must be taken into consideration vs. running a single product? All of those questions and more are included within and will give you a wonderful starting point to deriving answers that are relevant to your business.

Don't come looking for answers, rather come looking for insight and staring points. What you can learn from this book can be easily applied to your software product line or to the development of a new product line. All you need to understand is that what you will be reading will help you understand and not overlook many aspects of the overall business plan.

This was an interesting book to read. I certainly came away with a lot of respect for the authors, and their knowledge of product lines. I'm sure this is one of the best books available on the topic.

However, as a practitioner (more than a researcher), I was hoping for something a little more hands-on, with code examples and practical advice on creating a product line. Instead, this book focuses on the practices and processes that software managers would care about as they turn their point product(s) into a software product line. This is certainly important stuff, as failure to have management buy-in will derail the entire SPL effort.

In summary, a good book with a lot of detail, but don't expect an easy read, and don't expect to see lines of source code. Hard-core programmers should buy this book as a Christmas gift for their Manager/Director/VP.

In addition to having the book and reading it cover to cover I also took the class at the Software Engineering Institute taught by one of the authors. If I had written this book review in 2005, I would have said that this is critical for anyone who works for a software product company. As of 2008 I firmly believe that this book is absolutely critical for any architect involved in software development in IT, including those that work for large firms with extensive IT resources. Why?
This is about the discipline of creating software that is reusable, potentially portable and future proofed. It is about applying structured approaches to evaluate how a base of software should to meet the market needs. (Internal IT also has a market). The product philosophy extends beyond just software in large IT organizations, as the infrastructure platform as a product needs to be considered as well. This has become paramount as IT has the reality of immense numbers of permutations throughout large institutions.
So whether you are an aspiring architect in a software product company, or a large IT shop, this book is important to read and understand. You will never look at designing and programming the same after reading this.

As a side note, the growing need to have a product strategy within a large IT organization is covered especially well in the following book:
Next Generation Datacenters in Financial Services: Driving Extreme Efficiency and Effective Cost Savings (Complete Technology Guides for Financial Services)

UPDATE 10/24/2004:

I've been applying these concepts for over 5 years now (I wrote this review in 2001) and SO MUCH HAS HAPPENED. Go to Microsoft's site and search for "Software Factory" and read the dedicated Page.

In my book (Due Q1 2005) I make the case that the Agile process I have evolved (and the others) are actually moving us towards 'Product Line' and Factory concepts. Just Read 'Lead Software Development' by the Poppendiecks to see what I mean.

- DAMON

**************************

I'm the CEO of a company (agilefactor - http://www.agilefactor.com) that has recently made the successful transition to a product line focus. This book is by far the best reference I've found on the topic.

NOTE: I updated this to agilefactor but when I started using this I was CTO and Co-Founder of Monetaire, Inc.

Damon Carr, CEO and Chief Technologist
www.agilefactor.com
agilefactor

I got the book delivered within a week and the book was in the condition as mentioned.