Why is Reuse so Hard?

Is it only me, or is software reuse truly as difficult as it appears?

During my years in the medical technology industry I was able to observe a relatively small organization working many years on continuous and incremental improvement of a single core product. Reuse was an automatic result of our focus on a single core application domain and a single product that was evolved over the years. The connection to the customers was loose and delays were never more than an embarrassment.

When I moved into the automobile industry the picture changed. I was a member of a large, internationally distributed department. We were working on multiple customer projects in parallel. Most of these projects had huge similarities but every single one had its unique distinguishing factors as well. Instead of a long-term evolutionary plan for a single product, each project was strongly time-bound, budget-bound and subject to constant close tracking and scrutiny by the customer.

In this difficult situation it is natural that the company management will focus on the projects as unique entities, driving each to completion, on time, within budget to the best of their abilities. Reuse is one tool among many that is used to reduce engineering effort and costs. However, within a project it is impossible to invest additional effort or time to ensure that your new developments will be re-usable for future projects. That is not part of the scope of a customer project and a good project manager will block all such efforts.

So how is reuse accomplished?

The most common pattern is to copy an existing project and use this as a starting point for the new project. The problem is, that you inherit all the warts, architectural oversights, half-baked solutions and other problems along with the good stuff. When you strip out the things that don’t fit, this is usually done by engineers that were not on the original development team. How often are essential pieces stripped out because they weren’t understood?

Another problem with this “clone and own” reuse pattern is that every new customer project results in a new product line. Although the different product lines contain significant overlaps, these are hidden by the fact that they have separate and discrete code bases. Every improvement needs to be ported individually to all related projects. And don’t forget that this porting effort will encounter resistance if the problem hasn’t manifested in the other projects. The more important maintenance is, the bigger the headaches are.

During my time within Harman (prior to the advent of a new CEO and his destructive cohorts) we addressed this problem by building up a platform concept. We developed the MoCCAv2 framework which served to standardize the concept of components and component interfaces. Using this standardization as a foundation, it was then possible to build a huge library of components, subsystems and packages. These were then tested on several reference hardware platforms, allowing the platform team to offer proven and tested functionality. An additional benefit was the fact that improvements and other patches were available to all customer projects via well-established communication channels.

A key factor was the organizational structure. The platform project existed in the form of an internal project which was larger than the individual customer projects. Whenever possible, new developments required in customer projects were delegated to the platform. The goal of the platform project was to maintain and evolve the platform so as to be able to provide up to 80% of the functionality of any customer project off-the-shelf. This platform was a major contributing factor the rise of Harman to its then dominant position in the area of infotainment.

The two key factors here are

1. Organizational structure
2. Standardization

Anyone who claims that strong software reusability can be accomplished en passant within the context of customer projects should be challenged. I have only seen this working in the context of a single product with a single product line. IMHO, such claims demonstrate a lack of understanding for the problems involved. Choosing an organizational structure that makes reuse clearly visible as a high priority (e.g. by creating a platform department) is a strategic choice affecting organizational structure. As this article from Harvard Business Review explains, strategy and structure are strongly intertwined. This is also demonstrated by the fall of Harman from its leadership position after the platform was de-emphasized internally.

A natural outcome of such a platform concept will be standardization. This is a mixed blessing. Standardization forces the use of those paradigms that fit in the pattern of the standard. Some paradigms won’t fit and are effectively unavailable. Which limitations are acceptable, and which will have critical consequences? Which limitations will lead to simplicity while retaining the greatest possible degree of flexibility? These are key questions that need to be addressed. Unfortunately, there is no “one size fits all” solution.

‍