How Big is Your Software Inventory?

How Big is Your Software Inventory?

Wayne Lobb and David Warburton

In many companies, the true costs for developing and maintaining software often are not fully understood. Some symptoms of this misunderstanding within a company are chronic cost and schedule overruns in development projects, as well as persistent quality or performance shortfalls in the final product.

Labor costs for developing the software in electromechanical products now often exceed labor costs for developing the hardware. This change has come about during the careers of senior technical staff and executives, many of whom have little early career experience with software. They might not yet fully understand the product software development cycle and the true costs of the software shipped in their products. Software’s invisibility contributes to this misunderstanding.

The Accidental Software Firm

A great example of this occurred with a manufacturer of capital equipment for hospitals that grew to a Fortune 1,000 company by designing, manufacturing and selling common equipment found in every hospital room. The products were complex mechanical systems, and, over the years, the company became skilled in the design, manufacturing and field service forthe products.

In the 1990s the company advanced from electromechanical controls to microprocessor-based control, and for the first time, it added firmware engineers to the engineering staff.

Market drivers in the 2000s called for adding patient monitoring subsystems to the product line. This led to more software content and to additional software developers with new skills that went beyond control firmware. The company expanded further into device connectivity solutions and equipment tracking solutions, which brought in yet more software content and a wider diversity of software skills. The company’s product lines grew to include enterprise software elements, including relational databases and complex communications protocols that must provide totally reliable and secure information transactions—technologies far distant from electromechanical devices with which senior managementwas familiar.

Today, this company has more software and more software engineers than many pure software-product companies. However, the company still does not apply deep insight and skill to managing productsoftware in the way that it has historically managed product hardware in the form of electromechanical devices. There are still few or no equivalents on the software side for quality control, unit cost control andinventory management.

For this company, software development essentially remains a black box.

The company cited in this example is not the first to find itself in the software development business without the organizational expertise to manage it. Fortunately, there are techniques to manage both the costs of software and the software development process.

The first step is to understand how much software the organization is responsible for by assessing the company’s software inventory and developing effort/cost models. There is no one-size-fits-all method toassess a company’s software inventory. The methods need to reflect the company’s product profile within the context of itsparticular sector, industry and product line.

Defining the Size of Your Software Inventory

The “size” of software has to be viewed from the standpoints of quantity and complexity. Complexity comes from the intricacy and criticality of the software logic needed to meet the product’s requirements.

The software logic within a quick prototype of a small commercial device can be simple and cost relatively little to create and to test. By contrast, safety-critical software found in life-support equipment or sophisticated therapeutic systems usually is complex, difficult and expensive to build, though not always large in quantity. In life-critical systems, every possible contingency must be identified and addressed; therefore testing the software consumes a large fraction of the whole development budget.

Not all software should be counted in the inventory, and pure size—lines of software source code—is by no means the whole story. The primary rule we use when inventorying software by applying our own proprietary source-code-counting tool is this:

In order to be counted in the software inventory, source code should have real logic in it that your software staff (or contracted software staff) has created and/or modified themselves, by hand, and will go on modifying and supporting as an essential ingredient in your shipped products.

By logic, we mean conditional execution, e.g. “if XYZ condition is true, then do A, otherwise do B,” or “repeat this set of commands for N number of times.” Source code that does not have logic in it often is just data.

The Primary Rule’s qualifier of “logic only” countable code involves judgment. There is no automated way to apply judgment—each case can be different from every other one. Listed below are some of the secondary counting rules that could be applied:

• Third-party code: Do not count third-party source code used in your products unless your developers are modifying it on a regular basis. It is not uncommon to use free open-source utility software within a product, modifying the utility code slightly to integrate it; such source code should not be counted in an inventory.

• Test code: Do not count test codeunless:

– It was developed specifically for this product by your developers and,

– It must be debugged and maintained significantly over time.

• Configuration files: Do not count configuration files that have no embedded logic; for example, do not count typical property=value (.ini) files or .xml

data files.

• Data files: Do not count source files (C, C++, C#, Java etc.) that are used only to insert initial or unchanging data into a program or database. More generally, as is expressed above as the primary rule, do not count files that have no actual logic in them other than assignment statements and/or conditional compilation flags.

• XML files: Do not count XML unless it has actual logic embedded in it, and if it does have embedded logic then count only the logic, not the other information. XML mostly is used for configuration and test data.

• XML transformations: Do count .xls/xlst and other similar transformational logic that takes insight to develop, debug and maintain.

• Automatically generated code: Do not count automatically generated code as a rule, but certainly do count the fundamental logic that generates it. This can be complex given that modern graphical-user-interface building tools, such as Microsoft Visual Studio, tend to mingle auto-generated configuration code with your manually written code; in such contexts, it might be best to apply a constant discount fraction to the sizes of those particular files.

• Unused code: Do not count duplicated or obsolete (dead) code. Note that it can be very difficult to detect unused code when conditional compilationis involved.

Tools for Software Inventory

You can begin a software inventory by using free tools such as CLOC from SourceForge, or by using a commercial development tool such as Microsoft Visual Studio (MSVS), or Coverity’s static analysis suite. The result will be an uncalibrated approximation of the count that a detailed approach will generate.

For example, MSVS and Coverity will be highly accurate in their counts of actual used code in the shipped product. However, these tools often will not include test code or other ancillary code that should be counted, and they usually will include large data-defining source files that Foliage normally rules out based on our experience.

The goal, as expressed above, is to account for all of the logic, and only the logic, that your software organization has built itself and actively will care for indefinitely. A quick count using off-the-shelf tools can misrepresent the total by as much as 50 percent in either direction, either too low or too high. Management needs the inventory size to be accurate in order to plan properly. Engineering needs the size to be accurate in order for their estimates and evaluations within the company to reflect the reality of the work they have done and have yet to do.

Once you understand the size of your inventory, you can begin to assess the costs to maintain that software base and be able to use that information as the most valuable input it has for estimating future development costs. By doing so, you can avoid finding yourself in the software business without the organization expertise to manage it.

Editor’s note: This column is the beginning of a four-part series that will appear throughout the year, tackling the topic of what product software costs to build and own. The next installment will cover how much it costs to develop your software.

Wayne Lobb, Ph.D., is an engineering director at Foliage Inc., responsible for managing and

overseeing consulting projects and outsourcedsoftware development projects for manufacturers of semiconductor equipment, industrial equipment and medical devices. He has 25 years ofexperience in designing, building and assessingsoftware for computer-aided design, semiconductor manufacturing, and industrial equipment including various areas of nanotechnology. Lobb holds a doctorate degree in mathematics from the University of Illinois at Urbana-Champaign and an undergraduate degree from the California Institute of Technology. David Warburton is the director of Systems Engineering at Foliage. He has written numerous articles on medicaldevice development and has more than 20 years of experience in the medical device and robotics industry managing technology-intensive, new-product development projects. Warburton holds a master’s degree from the MassachusettsInstitute of Technology in mechanical engineering and an undergraduate degree in mechanicalengineering from Ohio Northern University.Foliage is a full-service product development firm based in Burlington, Mass., specializing in complex, software intensive systems.