Software Production Line

I heard this jargon about 18 months ago from Charles Krueger (www.biglever.com), at the time the organization I am working for suffered greatly from maintaining similar functionalities/implementations (I would say 90% commonality) for sheering number of products. We were using a branching/conditional flag (#define) mixed mechanism to tackle this problem. 

The mechanism had been there for years, initially works fine. As the codebase complexity grows (linearly in terms of lines, but exponentially in terms of functionality integration), We were facing the problem that one fix for product A does not go to the codeline of product B which use the same ASIC/SERVO/..., and the team of product B has to work on it again. A even worse case would be if the team for product B does not even aware the issue is solved for product A, and they created another solution, works fine for product B, and create one more problem when the codeline of product A and B integrated. It becomes a nightmare to some extent!!!

However, the issue still exists by now after 18 months effort. This reflects how difficult it is to resolve or influence the organization. I have no intention to reveal what the organization has done due to confidential issue, just some notes for recording purpose along the way.

The summary of Software Product Line, based on my understanding from discussion with Charles Kruger and learned from Web.

Software reuse/commonality is an increasing important issue across the industry. conventionally, there are 3 ways to resolve the Software product Line issue.

1. Simply use code-line branching, conditional flags, file parsing script to handle the problem.

It works fine for some organizations, especially if their product comes from the same codebase but very rare future commonality, and especially if the branching convention or conditional flag convention can be defined properly, makefile (or use a bigger name - build procedure) and the organization get used to it.  This approach can work even better than the advanced approaches below because there is no deployment or specific domain knowledge overhead.

2. Tools like Koala compiler, can take in variant definition, generate and codebase and compile. This approach has pros and cons, depends on the tool is implemented and deployed to the organization. The general rule is there should not be run-time overhead.

3. Tools like Gears. As Charles Kruger said, it is a totally new approach to replace all the above methods. I have strong interest to test it. However, I have not tried so far for various reasons, so no comment.

Based on my observation, many organizations could do some fundamental stuff on improving the SPL situation, before they jumped into all the technical concept and tools.

1. To the bear minimum, make each component into its separate directory and make it pass compile independently; The code modularity helps mitigate the software variation problem significantly. At least with the design and test work partitioned,  the number of issues won't multiply to each other.

Soft approaches like improve team communication, have better development policy will mitigate the problem, and these soft approach won't solve the componentizing issue. The hard approach is to generate a compile time (better), or run time error when the regulation is violated.

2. Define searchable conditional flag conventions/or branching naming convention For code with over 70% commonality, use source file interpolated with conditional flags. If you worry about the readability, find a editor to help you;

1) Keep you branch as minimum as possible, avoid local workspace.

2) have some home-grown flag tools if necessary.

3. The software componentizing solution (which partially solves the software variation problem) is not only limited to compilation stage. It is inherited from design, and extends to unit test, system test, production, and so on. There could be many things to talk on this. but to the bear minimum, have a way to do proper unit test, or subsystem test.

4. It is important to keep modularization and have reasonable diversity control mechanism (branching policy/convention, conditional flag naming convention, clustered makefile, or variant control tools) in place priori to implementation. In reality, it maybe possible for small to medium scale project (<20 man-years). It usually not the case for industry scale large project, which can easily go to 1000 man-year effort (including deployment support). I have attempted to correct the codebase direction (1 million line code base) halfway. It is difficult, in terms of technology, as well as organization culture, and impact to releasing (customer call always have the highest priority). I can easily take more than 20 pages to describe the feeling.  However, the answer in short is to do it incrementally, and feedback the quality result to management team. Be prepared, it is a long journey.