Charles Krueger is founder of BigLever, a pioneer in software production lines. He recently spoke with Dr. Dobb's editor in chief Jonathan Erickson.
Dr. Dobb's: Henry Ford is given credit for the production line. What would he think of SPL?
Krueger: Henry's initial reaction would likely be negative. His great accomplishment came from engineering innovations that removed all product variation, so that the identical automobile could be reproduced over and over again, with an efficient means of production. He would likely recoil at the notion of deliberately reintroducing product variation into manufacturing -- be it systems or software.
With equal certainty, I believe the "SPL epiphany" would eventually bring a smile to his face, once he realized that his accomplishments in the efficient means of production had been extended from merely capitalizing on commonality to also incorporate feature-based product variation.
Dr. Dobb's: Where's SPL having the biggest impact?
Krueger: There are two characteristics that we consistently see in the big SPL success stories. The first is a compelling need or desire by the business for a game changing advantage. For example, a strategic business opportunity to dramatically increase revenue by rapidly expanding product and feature diversity in a product line. Or, a critical need to quickly respond to market turbulence by significantly increasing efficiency or reducing deployment time in a product line.
The second characteristic of current-day SPL successes is that they come from the revenue generating side of systems development organizations rather than groups such as internal IT development organizations. I attribute this to the fact that "top line" revenue generation in product development provides stronger SPL motivation than "bottom line" cost savings in IT.
The markets where we currently see the strongest pull for SPL are automotive, aerospace, and defense.
Dr. Dobb's: Can agile and SPL co-exist?
Krueger: The correlation between agile and successful SPL practice is very strong, although sometimes not explicit. For example, you wouldn't necessarily expect Aerospace & Defense organizations that are contractually bound by waterfall processes to have agile SPL practices. However, even though the process for deploying any individual system may be waterfall in nature, the overall process for efficiently managing an entire product line must be agile in order to rapidly adapt to unpredictable requests for new products, new features, evolving feature combinations, new diversity and changing boundaries for commonality.
Dr. Dobb's: When organizations opt for SPL, what hurdles can they initially expect?
Krueger: The biggest hurdles we encounter are around changing people -- their roles, responsibilities, job descriptions and processes. Changing technology is easy by comparison.
Development organizations are often based on a product-centric perspective, where the primary focus for a team or individual is on the development, delivery, schedule and budget for an individual product. The SPL approach gains its efficiency and effectiveness from a shift in perspective, changing from the "vertical" silo'ed product-centric perspective to a "horizontal" SPL-asset perspective that cuts across all of the products in the product line.
This organizational shift from vertical to horizontal perspective -- and the inevitable resistance to change by some of the individual team members -- is by far the biggest hurdle organizations experience. Because the SPL approach ultimately reduces complexity and overhead, the early detractors soon recognize and appreciate the benefits, so "hurdle" is the correct term. It is a short-term upfront obstacle.
Dr. Dobb's: What role does "testing" have in SPL?
Krueger: The SPL approach impacts tools, assets and processes across the full systems and software development lifecycle -- from requirements to design, implementation, and very importantly testing. The best answer to this question might be in terms of what we see happen when a test organization initially opts out of a transition to SPL practice. The upstream stages in the development lifecycle may increase their output by factors of 2 to 10, quickly overwhelming the test organization that hasn't implemented corresponding SPL efficiencies. The test organization becomes the high-profile bottleneck that prevents the business from realizing SPL benefits.
This illustrates that testing plays a critical role in SPL. We see the most value from two SPL-specific testing techniques. The first is automated unit testing that includes "variants" to match all possible implementation "variants" of a component or subsystem. Nightly or continuous builds and unit test execution for all component variants provides good visibility into the health of the overall product line. The second is integration and system test minimization, by sharing test results from common or similar tests across different products in a product line. Knowing when duplicate testing can be avoided across multiple products is somewhat of an art, but we have seen good results in organizations that strive to put test effort into the areas of highest payoff.
Dr. Dobb's: Is there a place for SPL in small groups or organizations?
Krueger: Absolutely. One of our earliest success stories was with a small startup company that needed speed and efficiency to roll out a large product line of similar systems, without the corresponding need to hire a large engineering team.
Also, we find that the most effective way for organizations to transition to the SPL approach is incrementally by small teams. For example, by first migrating a small subsystem team and then repeating to bring in one small team after another.
Dr. Dobb's: Do SPL and compliance conflict?
Krueger: Compliance introduces some unique challenges to SPL that might initially appear as conflicting, but that can ultimately be turned into positive opportunities. Imagine creating a commercial avionics system product line under strict FAA DO-178B compliance. If you introduce an enhancement to a software component that is shared across multiple avionics products in your product line, have you just introduced multiple re-certification burdens for the component in each of your products? If you aren't careful, the answer is a costly "yes". But with well-defined SPL impact analysis and change management processes, the controlled introduction of this change into different product baselines and shared certification effort across multiple products in a single baseline can actually result in less overall certification effort and lower defect density in your systems.
Dr. Dobb's: What's unique about BigLever's approach to SPL?
Krueger: BigLever provides technically innovative and advanced SPL tools, methods and framework, but what is truly unique is our intense focus on the pragmatic issues that enable predictable and successful SPL deployments and benefits. Our patented Gears SPL Lifecycle Framework provides consistent and integrated SPL engineering throughout the lifecycle, from product line management to requirements, design, implementation, testing and deployment. We have pioneered a "second generation" SPL approach with an out-of-the-box solution for automated configuration of all product line assets across the lifecycle, using concise "feature profiles" to indicate which product capabilities to include or exclude in any particular product.
BigLever's SPL framework makes it uniquely easy to transition to the SPL approach by allowing organizations to utilize their existing legacy assets and their preferred engineering tools as the basis for their SPL practice. BigLever has a unique 3-tiered SPL Methodology that pioneered and validated techniques that now enable organizations to make incremental and non-disruptive transitions to SPL practice.
Dr. Dobb's: What does it mean when we talk about "second generation SPL"?
Krueger: First generation SPL (1G SPL) approaches showed how organizations could reuse existing SPL architectures and software components to more efficiently create new product variants in a product line. However, the effectiveness of 1G SPL was hindered during product evolution and maintenance, due to the reliance on "application engineering", where each of the individual products in the product line were maintained as cloned copies or branches. This led to an exponential growth in effort and complexity around branching, merging, impact analysis and interdependency management. We observed that this complexity in 1G SPL was responsible for the limited degree of success and adoption in the early days of the SPL industry.
Second generation SPL (2G SPL) approaches address this limitation by creating, evolving and maintaining a single, consolidated "superset" collection of product line assets, for each stage in the engineering lifecycle, and then using an automated "SPL configurator" to automatically assemble the "subset" of the product-specific assets required to match the features for any particular product. Maintaining the consolidated assets with 2G SPL is dramatically simpler than was possible with the multiple clones of 1G SPL. The 2G SPL approach is leading to much higher degrees of success and adoption by the mainstream industry.
Dr. Dobb's: Do changes in technology -- new programming languages, new platforms, etc -- affect SPL implementations?
Krueger: The impact will be comparable to what engineers are already familiar with in changes in technology for individual products or systems. There is really nothing special about SPL when it comes to technology evolution. For example, changing an embedded software component to a networked service will be similar if that component is part of a one-of-a-kind system or if that component is reused as part of dozens of different systems in a product line.
Dr. Dobb's: Microsoft and others have talked about "software factories." How does this tie into SPL?
Krueger: Unfortunately the term "software factories" has been used over time to mean different things in different contexts, ranging from very general concepts such as repeatable software development processes to very specific concepts such as a particular SPL approach. Microsoft has used the term "software factory" to describe it's solution for creating domain-specific languages (DSL) and DSL compilers for a system of similar systems, thus it is an SPL approach that is appropriate for the subset of product lines that can be expressed with a DSL. But in general, SPL and software factories are not always used to mean the same thing.