This week we hosted the 22nd International System and Software Product Line Conference in Gothenburg and I had the honor of being the general chair for the conference. Software product line research is concerned with the challenges associated with building a family of products from a shared platform. These challenges include managing variants, balancing platform development and product development, feature models, etc.
In a world where the size of software for most companies goes up with an order of magnitude every 5 to 10 years, one would assume that the need for reusing software is only increasing. And, with companies adopting continuous deployment, the cost of manually pushing out software for every product that your company has in market at the end of every agile sprint is easily becomes unmanageable. Obviously, the best solution for this is automatic product software derivation from a single (product line) code base.
There is an interesting dichotomy when it comes to software reuse. Software built outside the company is reused to a very large extent. Open source software ranging from Linux to MySQL and from WordPress to Apache enjoys enormously broad distributions. Commercial software, ranging from the Windows operating system to AUTOSAR base software components, is also broadly used and when companies mention that they have tens of millions of lines of code in their products, this is obviously counted as well.
When it comes to sharing software built inside the company, however, the story is fundamentally different. Although some companies do successfully develop and use platforms within the company, in the majority of companies, for a variety of reasons, the amount of reuse between product teams is highly limited and significant duplication of effort takes place. The result is that, according to our research, 80-90% of all R&D resources is spent on commodity functionality. That means that 8 or 9 out of every 10 people in R&D are working on things that no customer gives a flying hoot about. Stuff that should just be there and work, but that the product team should not spend any time on.
Many moons ago, I published an evolution model as shown in the figure below. The model suggests that starting from a set of independently developed products, the first step should be to standardize on the externally sourced software. Then, the focus should be on developing a platform that includes only features that all products need. The next step is a full-fledged product line where the shared software assets contain functionality used by a subset of products, meaning that variability management becomes a challenge. The final step is the configurable product base where each product or customer configuration is automatically derived from a common code base that contains the superset of all features and functionality.
Figure: Model of evolution of software reuse
Concluding, I realize that reuse, platforms and product lines easily are viewed as waterfall-ish, focused on requirements, planning and architecture work and consequently seen as non-agile. The point is I am trying to make here is that it’s very hard to be agile when you’re carrying around the anchor of tons of commodity software. Building on top of a solid platform providing the commodity functionality and focusing your energy on the differentiating functionality is a much smarter way to achieve agility, time to market and a high degree of effectiveness. So, stop wasting resources and do platforms already!
