Electronic Design

Be Careful When Specifying Shared Components

Imagine that a large software company has created a major new operating system and wants to maximize the use of shared components. For the sake of argument, let's call these items DLLs. This company believes that the shared components will reduce software size and programming, testing, and maintenance costs. On the surface, this expectation seems quite reasonable. But let's look a bit deeper.

Programming costs and software size will probably go down due to these shared components, though by much less than the company expects. Shared components are more general-purpose than their more specific counterparts. As a result, they typically take longer to specify, code, and test.

Some software developers estimate that such general-purpose components have three to five times as many lines of code as their unshared counterparts. So, they must be used three to five times to get any reduction in size or programming cost.

Although total component testing times may decrease with shared components, system testing times can grow astronomically. Since the components accomplish complex functions, they must be periodically revised. Third-party software developers will try to use the most updated version. What does the combination of multiple shared components and multiple revision levels do to the testing problem?

Assume you have 50 DLLs, and that each of the DLLs that you create appears in 10 possible revision levels. How many possible combinations of DLLs must be tested to ensure that they will all work together? 1050! If each combination took 1 ns to test, how long would it take you to test all of the possible configurations? 3 by 1033 years! This is much longer than the predicted life of the universe.

Furthermore, it wouldn't make sense to test all of these combinations. Only a small fraction would ever be used during the life of the system. Most of the time and money you would spend on thorough product testing would ultimately be wasted.

To avoid this waste, you might test the product as thoroughly as you could, and then sell millions of beta releases of the software. The actual complaints from these beta customers would give you an accurate picture of which configurations occur in the real world. Testing costs, then, can dramatically rise with rapidly evolving shared components, which would affect both development and maintenance costs.

There's an important lesson here for product developers. Be very careful when you use rapidly evolving shared components. While such components promise lower development expenses, they can easily make products untestable. If you must use them, use as few as possible.

For example, if we cut the number of DLLs in half, we reduce configurations by a factor of 1025. Alternatively, by cutting the number of revision levels in half, we can reduce the number of configurations by a factor of 1015.

Shared components won't inherently make a product untestable, but they still must be managed carefully. Too often, companies only focus on the savings in development expense they expect to achieve and forget that shared components impact other areas. Try to consider all of the costs, understand what drives them, and manage them with care.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish