How Do Your Costs Compare to Your Competition?

How Do Your Costs Compare to Your Competition?

Part one of this series introduced the concept of “Software Inventory,” which was defined as the number of lines of source code that are an essential ingredient in a company’s shipped products (March issue of Medical Product Outsourcing). As is the case with many companies’ strategic assets, this software inventory has both an acquisition cost and an ongoing maintenance cost.

Part two (June issue) described some approaches to calculating these costs, and understanding the underlying factors behind them. This article, part three in the series, explores some of the factors that will affect these costs in different companies and industries.

How Do Inventory Size and Efforts/Costs Compare?

In part two, we introduced the observation that over time, software staff members who are full-time employees produce and support, on average, around 700 new or changed lines of software logic per person-month, or equivalently some 8,000 lines of software logic per person-year.

We also have observed that over the lifetime of a body of software, each full-time software research and development (R&D) employee typically accounts for about 50,000 source lines of software logic. In this accounting, R&D employees include developers, architects, testers, documenters and technical managers. Before first shipment to customers, the total per R&D staff member may significantly be higher than this, prior to when maintenance begins and support staff become involved. Late in the life cycle the number of lines per R&D employee may increase again, when little, if any, new development is happening and nearly all the work is in minor fixes.

These numbers are averages, and an individual organization may fall above or below these averages for one or more reasons. It is important to understand the factors that influence the productivity of developers and cost of the company’s software so that management can make informed decisions on the size and composition of the software development staff.

It is important to be aware of the nine factors that influence software development team productivity:

1. Safety-critical software: Regulateddevelopment for safety-critical software such as Class III medical device software usually runs closer to 400 lines per software staff-month, less than the 700 lines per month in non-regulated development. A highly skilled and experienced software group in a regulated environment can produce much more than 400, however, but only over time and with very strong management. In the best case, regulated development should require no more than 10 percent extra effort and cost beyond theaverage numbers.

2. Organization size: Productivity in large organizations—100 software staff and up—tends to significantly be lower than in small organizations. Communications overhead grows rapidly with increasing size unless managed extremely well. Staff members in large organizations tend to multitask more with multiple responsibilities, consequently suffering more ramp-up/ramp-down time, resulting in a greater loss of productivity. We have observed on the order of 25 percent lower productivity in large organizations.

3. Distributed development: Software developed by teams that are not physically proximate costs more to build than by teams that are co-located. The communications overhead is higher across geographical, time zone and cultural distances. On the other hand, there may be good reasons to distribute the development among sites to have certain kinds of development close to end customers for faster feedback and a better cultural fit. Cost savings rarely are as great as one might expect for offshore development. Lower hourly rates are counterbalanced by lower skill levels, more staff turnover volatility, the need for more extensive and rigorous requirements to be provided, and by the various overhead costs of distance.

4. Organization skill and experience: Excellent developers build less code to accomplish a task than less capable developers. They also build the code much faster, and the code they produce has far fewer problems. The difference in problem-free output between the most capable developers and the least capable developers can be as high as 10:1. Foliage has observed isolated instances of more than 50:1.

5. Staff focus: Productivity tends to significantly be higher than average in a startup, or at a company that only builds software and systems products on contract. Engineers in these situations rarely have to multitask and can sustain very high levels of productivity when building new systems. This places the tightly focused design teams at contract companies at a cost advantage to internal teams when the development cost is measured on a cost per output basis. Focused teams have two other major advantages: the speed with which a new product can be brought to market and the lower number of defects and issues in software developed by a highly experienced, fully focused team.

6. Complexity: The more complex a problem that’s being solved, the more complex the software generally has to be. This leads to lower apparent productivity in terms of lines of code. Software complexity most commonly is measured by counting the number of different paths through a body of software logic; the total number is known as the McCabe metric for that body of code. The McCabe metric can be misleading. For example, a large case statement may totally be simplistic conceptually, but get counted as highly complex. It is essential that your company understand the true inherent complexity of the problems you are solving and the necessary complexity of the software you are producing before evaluating productivity on a lines-of-code basis. One way to do this is to have outside experts help you gauge specific challenges as compared with other companies in your industry.

7. Development for reuse: Software that is built for a single product or for a single purpose significantly is less complex than software that is intended to be reused in multiple contexts, e.g. in several products in a product line. From a distance, it can seem that reuse should be simple to achieve given the similarity of functions between different products, but the similarity often is only superficial, and design for reuse will be much more costly than anticipated. In the best case, development for reuse typically incurs a 100 percent premium in effort and cost, which means that in practice it’s usually better to build twice for two uses and seek reuse only when there are three or more distinct, but not fundamentally different, usages.

8. Robustness of the architecture: A hastily built body of software that has not carefully been designed with optimal requirements will cost far more overall than it needed to during its lifetime. This is because a poorly fitted system, whatever its context, will have more friction and more problems than a well-fitted one. Costs can skyrocket where there’s a bad fit. An excellent original architecture can degrade over time if developers do not follow its design principles and instead take shortcuts when enhancing or fixing the code.

9. Evolution versus new development: Productivity rates based on line counts are much higher than average for software development that refurbishes old or existing software. These evolutionary projects typically migrate to new technologies or infrastructures, or expand internal structures to enable advanced features or higher performance. In these cases, the monthly effort-line numbers can be as high as 2,000 lines per staff-month and in some cases as high as 10,000 lines per staff-month.

Editor’s note: This column is the third installment in a four-part series tackling the topic of what product software costs to build and own. The next column will expand on comparing your costs to those of your competition by providing some examples about how the techniques described can be applied and the consequences of both under-investing and over-investing in your software inventory.

Wayne Lobb, Ph.D., is vice president and engineering director at Foliage, responsible for managing and overseeing consulting projects and outsourced software development projects for manufacturers of semiconductor equipment, industrial equipment and medical devices. He has 25 years of experience in designing, building and assessing software 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 CaliforniaInstitute of Technology.

David Warburton is the director of Systems Engineering at Foliage. He has written numerous articles on medical device 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 Massachusetts Institute of Technology in mechanical engineering and an undergraduate degree in mechanical engineering from Ohio Northern University. Foliage is a full-service product development firm based in Burlington, Mass., specializing in complex, software-intensive systems.