Technical Note Issued: 07/2006 Limits of Software Reuse L. Holenderski Philips Research Eindhoven c Koninklijke Philips Electronics N.V. 2006
Authors address: L. Holenderski WDC3-044; leszek.holenderski@philips.com Reviewers: R. van Ommering WDC2-034; Rob.van.Ommering@philips.com H. Jonkers WDC2-032; Hans.Jonkers@philips.com c KONINKLIJKE PHILIPS ELECTRONICS N.V. 2006 All rights reserved. Reproduction or dissemination in whole or in part is prohibited without the prior written consent of the copyright holder. ii c Koninklijke Philips Electronics N.V. 2006
Technical Note: Title: Author(s): Limits of Software Reuse L. Holenderski Project: Customer: Friday Afternoon Philips Research Keywords: Abstract: software-productivity, software-reuse Software reuse is considered one of the main techniques to increase software productivity. We present two simple mathematical arguments that show some theoretical limits of reuse. It turns out that the increase of productivity due to internal reuse is at most linear, far from the needed exponential growth. Even worse, the linear increase can only be sustained during the first several years of applying internal reuse (later it saturates to a constant). With external reuse one can achieve exponential increase of productivity, at least in theory. Unfortunately, the price paid for the exponential growth is diminishing innovation. In fact, the innovation ratio due to external reuse diminishes exponentially fast to zero. Conclusions: Software reuse, either internal or external, cannot solve the software productivity problem, if employed as the only technique to increase software productivity. At least, not in a longer term. This is due to some fundamental theoretical limitations. We show that internal reuse saturates, leading to a constant growth that is far from the needed exponential growth. On the other hand, external reuse leads exponentially fast to diminishing innovation ratio. Despite the theoretical limitations software reuse can still play an important role in a software development process. First, it is one of the simplest techniques to increase software productivity, and thus should be applied whenever possible (i.e., whenever the cost of reuse is acceptable). Second, software reuse can directly contribute to innovation, in software intensive products. In particular, internal reuse can substantially contribute to incremental innovation. For example, product families can easily benefit from internal reuse. On the other hand, external reuse can contribute to radical innovation. By applying external reuse one can concentrate most of internal resources on the implementation of the innovative part of a new product instead of wasting them on commodities. Since the increased software reuse cannot, by itself, solve the software productivity problem, some other strategies must be developed and applied in combination with reuse. Especially those that increase the individual productivity of programmers, like higher level notations and sophisticated software development tools. But this is an entirely different story. c Koninklijke Philips Electronics N.V. 2006 iii
iv c Koninklijke Philips Electronics N.V. 2006
Contents 1 Introduction 1 2 Software productivity gap 1 3 Limitations of internal reuse 4 4 Limitations of external reuse 5 5 Benefits of reuse 6 6 Conclusions 7 References 9 c Koninklijke Philips Electronics N.V. 2006 v
vi c Koninklijke Philips Electronics N.V. 2006
1 Introduction In the quest for increased software productivity, software reuse is considered one of the main weapons in the battle to narrow the exponentially growing software productivity gap. We claim that if this is the only weapon used, the battle will be lost. In what follows we give two simple mathematical arguments that expose some fundamental limitations of software reuse, when it is applied to increase software productivity. The arguments are based on a few simplifying assumptions. The assumptions are carefully chosen to make our reasoning general and independent of any particular software development process. We consider two forms of software reuse: internal and external. Internal reuse is to use, in a new project/product, the software already developed for another project/product, inside the same company. External reuse is to use software developed elsewhere (like 3 rd party components, outsourcing, Open Innovation). In this document we are only concerned with the simple mathematics that shows the fundamental limitations of reuse. In particular, we do not discuss other disadvantages of reuse, like its cost. The main result of our formal analysis of software reuse is that employing this technique alone is not enough to solve the software productivity problem. Other techniques, like increasing productivity of individual programmers, must also be employed. However, we do not elaborate on other techniques here. 2 Software productivity gap In any non-trivial software development project, many people are involved (architects, programmers, managers, just to name a few). For this reason, software productivity is often perceived as a mostly sociological phenomenon, and thus very difficult to analyse rationally. The first problem to overcome when attempting a formal analysis of software productivity is to find a model that abstracts the sociological aspect out. In this section we present such a model. In our model, the software productivity problem is reduced to just one parameter: the number of lines of source code (later referred to as LOC) needed to be written. This extremely simple model is tailored to the analysis of the reuse problem, and we do not claim it is general enough to tackle other problems related to software productivity. In particular, we do not try to use it to estimate productivity of individual programmers. The Moore s Law stipulates that the number of transistors that can be packed on a fixed area of an integrated circuit grows exponentially, in time. This exponential growth has been observed for the last 40 years (as doubling the transistor s density every 18 to 24 months, on average) and we assume it will continue for some time to come. Our assumption is supported by [1, 2, 3], for example. A simple consequence of the Moore s Law for software developers is that the size of c Koninklijke Philips Electronics N.V. 2006 1
log(size in MB) 1500 1000 500 2K Pro XP Pro Moore 250 100 NT 4.0 98 ME 50 25 95 8 3.1 3.11 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 year Figure 1: Distribution size of Windows OS memories one can put into new products grows exponentially, and this means that the size of binary code put into new products must grow exponentially. Why must and not could? Because of competition (your competitors may utilize this possibility and so you must do it too). 1 One may argue that this is not necessarily the case, since the growing memories can be utilized for data rather than for code. However, even if most memory, say 90%, is utilized for data, the remaining 10% still grows exponentially. We give two examples that can serve as a direct evidence for our stipulation that the binary code put into products grows exponentially. The first example is from Microsoft (see Figure 1). It shows the size of successive binary distributions of the Windows OS software (data for the graph obtained from [4]). The second one is from Philips (see Figure 2). It shows the size of binary code put into TV sets, over the last 20 years (the graph borrowed from [5]). In both cases, the size of binary code grows in almost exact accordance with the Moore s Law. Notice that the size of binary code is in direct proportion to LOC, for a particular programming notation used. Although the exact value of the proportionality constant is not important for our further reasoning, we estimate it to be in the range of 3 to 5, in case of language C, for example. In other words, the number of machine instructions a C 1 In fact, our claim that binary code must grow exponentially relies on yet another simple consequence of the Moore s Law: the computational power of microprocessors grows exponentially. Without the increased computational power the growing binary code could not be processed in a reasonable (say, constant) time. This would make its exponential growth impractical, and then the competition pressure argument would not apply. 2 c Koninklijke Philips Electronics N.V. 2006
Figure 2: Size of binary code put into Philips TV sets compiler generates for one C statement is between 3 to 5, on average. If binary code should grow exponentially, and its size is in direct proportion to LOC, LOC should also grow exponentially. Notice that this simple reasoning relies on a hidden assumption that we do not change the programming notation over time. (Without this assumption we could keep LOC constant if we managed to double the proportionality constant every Moore s cycle, by switching to a higher level programming notation.) This is the case if we assume, as we do in this paper, that reuse is the only technique employed to increase software productivity. Now the concept of software productivity gap can be stated precisely as the difference n t a t where n t is the LOC we need to put into a new product and a t is the LOC we have available (as a result of our programming effort) to put into the new product. Parameter t denotes time. For simplicity, we assume t ranges over natural numbers, by counting the Moore intervals (i.e., the intervals of time it takes to double the transistor s density in accordance with the Moore s Law, say 18 months). In our notation, if function f represents some LOC changing over time, f t denotes LOC at the end of interval t (with the exception of t = 0 that denotes some reference point in time the time we did our initial measurements). The observation that the size of binary code should grow exponentially can now be simply stated as n t = n 0 2 t, and the problem is how to keep n t a t = 0 over time. Especially so if productivity of programmers (measured in LOC of a verified code they can write in a fixed programming notation, per some unit of time) is constant, for which there is a strong c Koninklijke Philips Electronics N.V. 2006 3
experimental evidence. An obvious approach is to employ an exponentially growing number of programmers, to keep a t up with n t, but this cannot be sustained for a longer time. Other commonly used approaches are internal and external reuse. Their limitations are analysed in the next two sections. 3 Limitations of internal reuse Assume a company, say C, needs software in its products. For simplicity, let C release a new product after every Moore interval, and develop the needed software on its own, by a team of employed software developers (architects, programmers and managers). Assume the team s size is fixed over time and the team can develop l new lines of source code during every Moore interval. (Notice that l is constant over time, due to the fixed size of the team and constant productivity of individual team members.) Let us count a t (for t = 0, 1,...). For simplicity we start counting a t in the situation when the software developers can develop exactly what should be put into a product. In other words, we assume a 0 = n 0 = l. As explained in the previous section, n t = l2 t. If no special techniques are applied to increase software productivity, a t = l and the software productivity gap is n t a t = l(2 t 1), so it grows exponentially fast. Assume C applies internal reuse. We model internal reuse with just one number r called a reuse ratio. The reuse ratio is a real number between 0 and 1. It represents the percentage of software that can be reused from old products when developing a new product. We assume r represents the effective reuse, i.e., we put all the cost of reuse into r (by lowering it, if necessary). We also assume that C reuses software only from a limited past (since reusing old legacy is too expensive). For simplicity, we limit the past to the previous Moore interval only (this assumption is not essential). Under these assumptions, a t+1 = l +ra t. In other words, software available for a new product consists of the newly developed software plus the software reused from the previous product. Notice (or prove by an easy induction) that for 0 r < 1, this simple recursive equation defines in fact a geometric series: a t = l(1 + r + r 2 + + r t ) = l 1 r t+1 1 r To let a reader grasp the speed of a t s growth, in Figure 3 we show several plots of a t for various r (we fixed l = 1 so a t is measured in units of size l). Notice that a t is a monotone sequence whose limit, for t, is constant l/(1 r). This means that internal reuse saturates, after several Moore intervals, to a constant. Thus, after the saturation, the software productivity gap n t a t still grows exponentially. One may argue that before reaching the saturation point, during the first several Moore intervals, internal reuse can increase productivity by a factor close to 1/(1 r). We could then increase productivity by an arbitrarily large factor since 1/(1 r) diverges to when r converges to 1. One might then argue that although internal reuse is of no much 4 c Koninklijke Philips Electronics N.V. 2006
a t 6 r = 1.0 5 4 3 2 1 r = 0.9 r = 0.75 r = 0.66 r = 0.5 r = 0.25 1 2 3 4 5 6 t Figure 3: Several plots of a t for various r value in a long term, it could still be useful in a short term, to buy time. Unfortunately, this is not the case. If we treat r as a parameter in a t (r) = l(1 + r + r 2 + + r t ) then a t (r 1 ) a t (r 2 ), for r 1 r 2, so a t (r) is monotone. On the other hand, a t (1) = l(t + 1), so a t (r) is bound by l(t + 1), for any 0 r 1. Thus, a t grows at most linearly (in time) and cannot follow the exponential growth of n t, even in the initial period before reaching the saturation point. From the fact that a t grows at most linearly for any 0 r 1, one can also conclude that playing with r (by increasing it exponentially in time, for example) cannot make a t grow exponentially in time. 4 Limitations of external reuse In the external reuse scenario, company C decides to put into its products software developed outside C, in addition to the software developed internally. In symbols, a t = e t + i t where e t is LOC of external software and i t is LOC of internal software. The main sources of the external software are 3rd party components, outsourcing and Open Innovation. Using external software is supposed to decrease the cost of the overall software put into products by assuming that the external software is cheaper than the internal one. Although this assumption is questionable, especially if one adds to the cost of external software the integration costs, we do not argue with it here. First, this problem is well known and second, it is difficult to give a formal argument. Instead, we present here a less known drawback of the external reuse strategy that can be summarized by the slogan the more reuse the less innovation. c Koninklijke Philips Electronics N.V. 2006 5
In the equation a t = e t + i t, e t represents the part that is available not only to C but also to its competitors, while i t represents the part that differentiates C from its competitors. Thus, i t represents most of (if not all) innovation in a t, so i t /a t is a good estimate for the innovation ratio. The problem is that external reuse decreases the innovation ratio exponentially fast to zero. In order to see this, it is enough to observe that a t grows exponentially fast (since a t = n t = l2 t ) while i t is either a constant (if we do not employ internal reuse to develop i t ) or bound by a constant (if we do). The above reasoning relies on the assumption that innovation, when implemented in software, is in direct proportion to the size of the software, on average. One may argue that the assumption is questionable since small pieces of software (say, a tricky algorithm) can be very innovative. However, in a reasoning based on averages, we are allowed to ignore such examples. Although possible, they are exceptions and not a rule. If they were a rule we would not have the software productivity gap in the first place. One may also argue that what really matters is the innovation itself (i.e., i t ) and not the innovation ratio (i.e., i t /a t ), because the potential buyer of a product will pay attention only to the functionality implemented by i t and take for granted the functionality implemented by e t = a t i t, as this functionality is expected anyway. It turns out that this is not the case, due to a similar argument as before: if this was the case, to attract potential buyers, a new product would only need to differ from existing products by i t (which is a constant, or bound by a constant). As a consequence, a linear growth of innovation would be enough over time, and we would not observe the software productivity gap. 5 Benefits of reuse Despite the fundamental theoretical limitations outlined in the previous sections, software reuse can still play an important role in narrowing the software productivity gap. First, with internal reuse one can multiply productivity by a factor close to 1/(1 r) where r is the reuse ratio. For example, if r is close to 1, say 0.9, one may increase productivity 10 times. To be more precise, factor 10 is achieved at infinity. After t Moore intervals productivity increases by factor (1 r t+1 )/(1 r) and thus grows much slower. In our example, productivity grows initially as follows: 1.9, 2.7, 3.4, 4.1 and 4.7 (for r = 0.9 and t = 1,..., 5). Second, even better results can be achieved with external reuse since it allows to increase productivity without limits, at least in theory. To follow any desired growth a t it is enough to acquire external software of size e t = a t i t. Of course, there are practical limits to this approach if one factors-in the cost of external reuse, such as the cost of acquiring the external software and integrating it into a product. We do not know a simple and general theory that can express the practical limits of external reuse in numbers. An interesting topic is how software reuse can contribute to innovation. A popular wisdom distinguishes between incremental and radical innovation. The term incremental innovation refers to products based on a slightly changed technology (or idea) than previous products. Radical innovation refers to products based on a substantially different tech- 6 c Koninklijke Philips Electronics N.V. 2006
nology (or idea) than previous products. Following [6], we can also distinguish between sustaining and disruptive innovation. The term sustaining innovation means the kind of innovation needed to sustain an established position in a mature, but still evolving, market. It manifests by new features added to existing products. Disruptive innovation means the innovation leading to a new product that creates a new market. In principle, the two classifications are orthogonal, in the sense that all four combinations incremental/sustaining, incremental/disruptive, radical/sustaining and radical/disruptive are possible. In practice, there is some correlation between the two classifications since the combinations incremental/sustaining and radical/disruptive tend to be more common than the other two. In what follows we argue that the main role of internal reuse is to contribute to incremental innovation while external reuse is most helpful for radical innovation. Due to the correlation mentioned above, one may then extend this observation to sustaining and disruptive innovation. In order for internal reuse to have a visible impact on software productivity, the reuse ratio r should be close to 1, say 0.9. Recall that r denotes an effective reuse ratio (i.e., we put into r the organizational cost of internal reuse) so r close to 0.9 means in practice almost 100% reuse of source code. Such a high reuse of source code is typical for product families, and product families are typical for incremental innovation. On the other hand, incremental innovation can seldom benefit from external reuse since this kind of innovation is usually based on internal know-how, and not on external expertise. As far as radical innovation is concerned, we have a dual situation. Radical innovation can seldom benefit from internal reuse since there is usually nothing to reuse from, especially if we are going to build a software intensive product based on a really fresh idea. External reuse should be applied instead, to free as much of internal resources as possible, in order to implement the new technology (or idea) on which the new product is based. 6 Conclusions Software reuse, either internal or external, cannot solve the software productivity problem, if employed as the only technique to increase software productivity. At least, not in a longer term. This is due to some fundamental theoretical limitations. We show that internal reuse saturates, leading to a constant growth that is far from the needed exponential growth. On the other hand, external reuse leads exponentially fast to diminishing innovation ratio. Since the increased software reuse cannot, by itself, solve the software productivity problem, some other strategies must be developed and applied in combination with reuse. Especially those that increase the individual productivity of programmers, like higher level notations and sophisticated software development tools. But this is an entirely different story. Despite the theoretical limitations software reuse can still play an important role in a c Koninklijke Philips Electronics N.V. 2006 7
software development process. First, it is one of the simplest techniques to increase software productivity, and thus should be applied whenever possible (i.e., whenever the cost of reuse is acceptable). Second, software reuse can directly contribute to innovation, in software intensive products. In particular, internal reuse can substantially contribute to incremental innovation. For example, product families can easily benefit from internal reuse. On the other hand, external reuse can contribute to radical innovation. By applying external reuse one can concentrate most of internal resources on the implementation of the innovative part of a new product instead of wasting them on commodities. 8 c Koninklijke Philips Electronics N.V. 2006
References [1] The Future of Moore s Law, Technology & Research at Intel, http://www.intel.com/technology/silicon/mooreslaw/ [2] Platform 2015, Technology & Research at Intel, http://www.intel.com/technology/architecture/platform2015/ [3] G. E. Moore, No Exponential is Forever... but We Can Delay Forever, International Solid State Circuits Conference (ISSCC), Feb. 10, 2003, ftp://download.intel.com/research/silicon/gordon Moore ISSCC 021003.pdf [4] History of Microsoft Windows, http://www.computerhope.com/history/windows.htm [5] Erik Kaashoek, Software in CE and its impact on the Business Strategy, Philips Research Electronica Colloquium, July 3, 2006 [6] C. M. Christensen, The Innovator s Dillema, Harvard Business School Press, 1997 c Koninklijke Philips Electronics N.V. 2006 9