Dirk Riehle's Industry and Research Publications

What’s wrong in software product line engineering? Political power play between product units

In previous blog posts we identified

as causes for problems in software product line engineering. Of several more, I want to pick a third and final one, before we turn to the root cause of it all in the next blog post. This third cause is the political power play between product units as they try to prioritize requirements for the platform organization.

Specifically, in traditional application and domain engineering processes, the platform is jointly paid for by some corporate funds or the product units directly. These costs occur, no matter what, and are not tied to the prioritization and triage of requirements for the next release of the platform. As a consequence, there is no cost associated with fighting to get your requirements to the top of the list.

Read what engineering managers and software developers had to say about power play in product line engineering:

  • “A consequence of the power play between product units is that the platform drives the [domain engineering] process and involves product units only very late.” Developer (platform), case 1.
  • “We [platform organization] don’t know how to prioritize reusable asset requirements, and the product units are no help because each feature is most important.” Manager (platform), case 2.
  • “We didn’t understand the reusable asset requirements as communicated by the product units. […] Not much worked when we first delivered the component.” Developer (platform), case 1.

Power play and political infighting between product units leads to poorly prioritized requirements which in turn, from an overall perspective, lead to systemic overall delayed product delivery.

Why? A sane prioritization would have the benefit of the overall product line in mind, not the interests of the most powerful product unit or the technical interests of the platform only. One can argue that this is a failure of the domain engineering process and a sane process would lead to correctly prioritized requirements. However, the lack of sanity ensues because there is no cost associated with prioritizing and a better or worse run domain engineering process won’t change anything about it.

Finally, read about the root cause of it all: The separation of product units as profit centers from the platform as a cost center.

Newsletter subscription


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Share the joy

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes collaborative qualitative data analysis fun and easy.
EDITIVE makes document collaboration more effective.

Featured projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use