Applied Software Product Line Engineering Book Review

The authors of this book represent an all-star lineup of the best of the best in the Software Product Line Engineering (SPLE) field. They do a great job of providing a snapshot of the current SPLE best practices in the industry today. Each chapter is written by a different author, or team of authors. This leads to some different perspectives on SPLE. This works for this type of book, but it does provide a conflict in the points of view taken in certain chapters. If you have experience with SPLE this shouldn’t be an issue because you will already understand what those different views are, but for someone with little or no experience this could cause confusion. I found none of the points of view wrong, just different. Different domains require, and provide for, different approaches. I recommend this book to those that are experienced as a guide to the evolution of the topics covered, and to the beginner I would use it as a road map of topics you should learn more about in order to get the full understanding behind each chapter. Each chapter provides an excellent reference section. I would suggest also reading the following books. They provide more information about the material covered in some of the chapters. Software Product Lines: Practices and Patterns is mentioned several places in the book. It is key to getting a more in-depth look at the 29 practice areas and the patterns that help to apply them. Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures goes in-depth into the use of Product Line UML based Software engineering (PLUS). UML and PLUS are mentioned several places in the book. PLUS is what I use when I build a software product line. I have created a UML stereotype in SPARX EA which you can download here. The table of contents is below. ORGANIZATIONAL AND MANAGERIAL ISSUES Software Product Line Engineering: Overview and Future Directions A Roadmap for Software Product Line Adoption New Methods behind a New Generation of Software Product Line Successes Evaluating Product Family Development Using the Balanced Scorecard Approach Product Management for Software Product Lines: An Overview METHODOLOGIES AND PROCESSES A Systems Product Line Approach Adoption of Software Product Lines to Develop Autonomic Pervasive Systems Development of a Software Product Line for Validation Environments Building a Family of Compilers Formal Verification and Software Product Lines TECHNICAL ISSUES Multiple-View Requirements Models for Software Product Line Engineering Managing Flexibility and Variability: A Road to Competitive Advantage Feature Oriented Analysis and Design for Dynamically Reconfigurable Product Lines Separating Application and Security Concerns in Modeling Software Product Lines Architecture as Language INDUSTRY EXPERIENCES AND CASE STUDIES Management and Financial Controls of a Software Product Line Adoption Efficient Scoping with CaVE: A Case Study Model-Driven, Aspect-Oriented Product Line Engineering: An Industrial Case Study Evaluation of Design Options in Embedded Automotive Product Lines Product Line in the Business Process Management Domain I found the material covered to all be of great value. There are a lot of great case studies through out the book beyond the section of chapters that cover case studies. They help to take the practices covered from theory to reality. My biggest pain point with this book is the index. It is just down right sad. I am not going to ding the book for something technical the editors missed. I have been very tempted to grab an electronic version to make up for its weakness', although I have not seen one for sale. All in all if you are involved with Software Product Line Engineering at all, this is a mandatory read. Software Product Line Engineering is an evolving field and this book brings us up to date on the evolution of the field.

Recruiters... I really want a job... but please but please stop wasting our time

I get approximately a dozen phones calls and 15 emails a day when I put out my resume. If I answer just one of them, it is a good day. There are several reasons I don’t answer, and it baffles me as to why I received the call or email in the first place.

Recruiters, to help you stop wasting your time, I have listed a few reason I won’t answer you.

If your email or message contains “I know you are not interested in relocating, but this job opportunity may convince you to”, don’t call and don’t email. There is a reason I say at the top of my resume, and check “I won’t relocate” on the profile information. It is because I WON’T RELOCATE!!!!! And no I don’t know anyone who lives in Nowhereville, because I don’t live there!!!!

If I have to play your message more than 3 times trying to figure out what your phone number is… well honestly, it has become so annoying that lately I have only been listening twice. If I can’t get your number because you have mastered blabbering out your phone number in less than a microsecond, I don’t waste my time trying to figure it out.

I am a “.NET” Architect. I have zero interest in becoming a Java architect. No price, no hours, no location, and no title will change my mind. No they are not the same thing because they are both object oriented.

I tell you who I am, all about my experience, the rates I am looking for, and the locations I will work in, so I expect you to do the same. If I want to know where the location is, who the client is, what the rate is, and what the duration of the contract is, I expect to be told. Keeping that information secret does you no good. The clients always have more than one recruiter/head hunter looking, and not all of them think withholding information is to their advantage. We always find out eventually. If I don’t know the rate range, I won’t interview, so the first one to give me all the info I need to make a decision, is the one I go with.

When I say no thank you to a position, that actually means no thanks. I have at least a dozen recruiter’s emails going straight to trash because they have decided to not take no as an answer. I think they went through some sort of Tony Robbins Ninja Recruiting Seminars, and have been brainwashed into not hearing or seeing the word no.

We can figure out if I am a good candidate by email. Location, rate, duration, and job descriptions can all be sent by email. If those look like a match to me, I will call you. But I don’t have time to talk to 25 people a day, I have a full-time job. So just sending me a “call me”, usually indicates to me you don’t have a job available, and you just want to collect profile information on me.

Luckily I don’t have to complain about meet and greets because you all have lost you expense accounts in the current economy. But if you start getting them back, forget it. I know there used to be point systems. They got points for getting your resume, talking to you on the phone, meeting for lunch, and doing preliminary interviews with their staff. The more points at the end of the month, the bigger the bonus.

Last but not least. If you get me on the phone and say “tell me a little bit about your background”, I’ll hang up on you. Read the resume, that is what it is for. If you can’t read, have a friend read it to you, but do not call me to have me read it to you.

I hope this helps you save a little time, at least with me.