home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr6 / proceedings / ascii / malan.ascii < prev    next >
Text File  |  1993-10-19  |  19KB  |  370 lines

  1.  
  2.  
  3.  
  4.  
  5.                                Motivating  Software  Reuse
  6.  
  7.  
  8.  
  9.                                              Ruth A. Malan
  10.  
  11.  
  12.  
  13.                                    Hewlett-Packard Laboratories
  14.  
  15.                           1501 Page Mill Road, Palo Alto, CA 94306
  16.  
  17.                                            Tel:  (415) 857-7909
  18.  
  19.                                     Email:  malan@hplabs.hp.com
  20.  
  21.                                           Fax: (415) 857-8526
  22.  
  23.  
  24.  
  25.                                                   Abstract
  26.  
  27.  
  28.     In order to achieve levels of reuse that support attainment of the organization's objectives,
  29. a comprehensive approach to motivating reuse among all relevant players in the organization
  30. needs to be developed. This position paper explores some of the issues that arise in motivating
  31. reuse at different levels in the organization. It posits that an integrated solution that relies on
  32. organizational self-knowledge to align reuse incentives with reuse goals and the organization's
  33. ob jectives will be more effective than isolated attempts to eliminate the symptoms of reuse
  34. inhibitors.
  35.  
  36.  
  37. Keywords: reuse, incentives, economics, funding models, performancemeasures, organizations,
  38. management.
  39.  
  40.  
  41. Workshop Goals:  exchange perspectives on organizational and management aspects of sys-
  42. tematizing software reuse; networking.
  43.  
  44.  
  45. Working Groups:  reuse incentives, management, organization and economics; reuse process
  46. models; and reuse maturity models.
  47.  
  48.  
  49.  
  50.                                                   Malan- 1
  51.  
  52.  
  53. 1      Background
  54.  
  55.  
  56.  
  57. Under  the  visionary  leadership  of  Martin  Griss, HP  Laboratories'  Software  Reuse  Department
  58. (SRD) has put together a multi-disciplinary team to investigate the business, organizational, cul-
  59. tural and technical aspects of creating effective, reuse-based Flexible Software Factories (FSF's).
  60. During a Summer internship with SRD in 1992, the author participated in this research program,
  61. focusing on business issues. Continuing this work with the SRD-FSF team,the author is currently
  62. developing an integrated framework forproviding reuse incentives at various levels, incorporating
  63. organizational considerations, funding mechanisms, and project and personal performance evalua-
  64. tions that are consistent with reuse goals.
  65.  
  66.  
  67.  
  68. 2      Position
  69.  
  70.  
  71.  
  72. Reuse programs that fail to "get off the ground" frequently share the problem that the incentives
  73. to produce and utilize reusable components are lacking or subverted.  For example, when project
  74. managers  are  held  accountable  for  increased  costs  and pro ject  delays,  they  tend  to  avoid reuse
  75. investments.  In  such  an  environment,  an  edict  to  produce  reusable  components  is  not  likely  to
  76. be  very  effective  since  it  conflicts  with  project's  cost/schedule  p erformance.   Other  "knee-jerk"
  77. responses to the symptoms of reuse inhibitors may be misaligned with reuse goals. For instance,
  78. cash bonuses for component deposition may give rise to a large but worthless library. This is not
  79. to say that cash bonuses are necessarily bad, but that unlessthe overall picture is considered, the
  80. attempted "solution" may have undesirable consequences.
  81.  
  82.  
  83. It is generally recognized that attempting to eliminate a symptom rarelysolves the root problem,
  84. yet this is precisely what we often observe in the case of reuse.  To be fair, high pressure, tight devel-
  85. opment cycles make it hard to distinguish problemsfrom symptoms.  It is, therefore, important to
  86. invest in up-front analysis to develop a systemic understanding of the software development organi-
  87. zation, it's goals, processes, people, opportunities and challenges. Armed with this self-knowledge,
  88. the organization is better able to create an integrated solution to theproblem of achieving levels
  89. of reuse that are aligned with it's overall objectives.
  90.  
  91.  
  92.  
  93. 2.1     Getting Everyone "On Board"
  94.  
  95.  
  96.  
  97. 2.1.1     Incentives at the Software Engineer Level
  98.  
  99.  
  100.  
  101. Extrinsic Incentives
  102.  
  103. A number of companies, including Motorola [1], and Hartford Insurance Group [2], have installed
  104. a reward system to counter low deposition and reuse rates of library components.  An organization
  105. considering use of rewards should assess how the reward system interacts with intrinsic motivators
  106. such as personal objectives and performance measures.  For instance, reuse bonuses may conflict
  107. with the disincentive created by evaluations based solely on lines of new code developed. Further-
  108. more, any proposed reward system should be analyzed to establish whether it does indeed foster
  109. behavior that is consistent with reuse goals. For instance, while flat rate cash bonuses make the
  110. incentive program relatively easy to administer, they do not tie the bonus to the value of the com-
  111. ponent (though a bonus per use at least rewards creation of useful components).  A bonus based
  112. on consumer savings is more likely to stimulate production of valuable components.
  113.  
  114.  
  115.  
  116.                                                          Malan- 2
  117.  
  118.  
  119. Intrinsic Incentives
  120.  
  121. Different engineers take pride and pleasure in different aspects of reuse-related work. Some software
  122. engineers are motivated by the desire to pro ducemore p ermanent software assets that bear their
  123. stamp of creation through generations of products. Others are more happy to focus on the unique
  124. aspects of customer solutions. Taking into account individual preferences as well as talents when
  125. filling reuse roles will help to align intrinsic motivators with reuse goals.
  126.  
  127.  
  128. The argument that there is an inherent motivation to reuse available components whenever doing so
  129. will save effort and time may seem persuasive, particularly when the pressure of tight development
  130. schedules is considered. However, the height of this pressure comes fairly late in the development
  131. cycle, after many of the design and implementation decisions have already been made, so that the
  132. number of code components that will slot into the project at that point is likely to be severely lim-
  133. ited. Therefore, incentives to reuse earlier phase work products need to be considered. Evaluating
  134. the exploitation of reusable work products during inspections at each phase has proved to be an
  135. effective practice in a number of HP's pilot reusepro jects. Thus, reuse is fostered by incorporating
  136. reuse levels in project and individual performance evaluations. Performance evaluations are power-
  137. ful motivators and traditional performance measures cannot be left intact when reuse programs are
  138. initiated. New measures must be designed to take the reuse goals into account. Of course, the or-
  139. ganization is in the business of making products, and reuse is only ameans to that end.  Therefore,
  140. care should be taken to ensure that the incentivesystem is designed to motivate reusable component
  141. production and utilization where it effectively supports the organization's broader ob jectives.
  142.  
  143.  
  144.  
  145. 2.1.2      Incentives at the Project Level
  146.  
  147.  
  148.  
  149. Divisions, R&D groups, and even project groups are typically responsibility centers and financial
  150. measures  are  used  to  evaluate  their  performance  and  allo cate  rewards  and  corporate  resources.
  151. Where reuse crosses responsibility center boundaries,the costs of reuse reflect badly on the producer
  152. responsibility center if there is no mechanism toreallo catesome of the consumer's benefit to the
  153. producer. In such cases, even if reuse is mandated by upper management and allowances are made to
  154. support production of reusable components, reuse goals tend to be subverted. Because production
  155. of reusable work products does not directly contribute to current pro duct development, it is hard for
  156. project managers to resist raiding reuse producer resources under their control whenever product
  157. development  projects  come  under  pressure.  While  the  cost  of  lost  opportunities  for  the  overall
  158. organization may far exceed any lost opportunity cost to the subgroup housing the production for
  159. reuse, it is the latter cost that is both most apparent to product managers and the basis for their
  160. evaluation. Some possible resolutions to this incentive problem are outlined below.
  161.  
  162.  
  163. Producer Group as a Separate Cost Center
  164.  
  165. One way to circumvent the need to redistribute reuse benefits, is to separate component producers
  166. and support personnel from project teams, and make the producer and support groups cost centers.
  167. This approach may still encounter problems if the producer cost center is housed in a divisional
  168. profit  center  when  reuse  of  the  components  crosses  divisional  boundaries.   This  is  because  the
  169. division that incurs all of the reuse investment does not receive all of the benefit. If this is the case,
  170. the cost center should be placed at a higher level in the organization.
  171.  
  172.  
  173. Barter
  174.  
  175. One approach to evening out the reuse investment burden is to allocate the development of com-
  176. ponents  to  members  of  a  "consortium"  of  development  pro jects.  This  barter  system  has  some
  177. appeal because the exchange obviates the need to establish prices or torestructure the organiza-
  178.  
  179.  
  180.  
  181.                                                          Malan- 3
  182.  
  183.  
  184. tion.  However, as the pressure to get products out rises, engineers tend to get shifted from reuse
  185. production/support activities to more directly product-oriented activities.
  186.  
  187.  
  188. Transfer Prices
  189.  
  190. Transfer pricing is one of the most frequently used mechanisms for providing supplying responsibility
  191. centers with market-like efficiency incentives.  Where there isan external market price, that is the
  192. most efficient transfer price to use.  In the context of domain-specific reuse,  however,  it is likely
  193. that in many cases components will be regarded as proprietary and essential to the organization's
  194. competitive advantage, so that no external market will exist. There are a number of other possible
  195. approaches to setting the transfer price.  One alternative is toset the total transfer price equal
  196. to the producer's cost, and to charge consumers some portion thereof. Even this approach is not
  197. straightforward  in  the  reuse  context,  since  future  reuse  instances  are  uncertain.  Bollinger  and
  198. Pfleeger [3] identify a number of possibilities for amortizing the producer cost, including flat rate
  199. amortization, biased flat rate amortization, and accelerated amortization.  Another alternative is
  200. to allow the managers involved to bargain over the components to be delivered, and the transfer
  201. price to be paid for them.
  202.  
  203.  
  204. Incentive to Utilize Reuse Components
  205.  
  206. Product teams are responsible for the development of products best suited to their target mar-
  207. ket segment, and high levels of reuse are generally attained only at the expense of some degree
  208. of  compromise  on  individual  optimization  of  features  and  performance.  The  functionality  that
  209. is considered common to a group of products is frequently a decision variable that is subject to
  210. tradeoffs between better suiting individual customer segments, and extending the commonality and
  211. consequent economies of scope in development and maintenance.  As a result of the tension between
  212. individual product optimization and product family benefit from reuse, the estimated reuse benefits
  213. and the progress toward attaining the expected benefits should be shared with thepro duct teams
  214. so that they can make informed tradeoff decisions. Fortunately, however, this tension is somewhat
  215. ameliorated in many markets where customers are coming to value greater consistency in product
  216. lines because this allows them to share their investment in training,  documentation,  peripherals
  217. and the like among related products. This enhances the software development organization's op-
  218. portunity  to  broaden  the  scope  of  common  functionality  and  retain  the  loyalty  of  customers  to
  219. boot.
  220.  
  221.  
  222.  
  223. 2.1.3      Incentives at the Upper Management Level
  224.  
  225.  
  226.  
  227. Upper management support is vital to the success of the program, not only b ecause the investment
  228. in reuse may be high enough to require their authorization, but because reuse entails significant
  229. change in the way project-organizations operate. Organizational change typically meetsresistance,
  230. and high level leadership plays an important rolein instilling a vision that inspires and motivates
  231. those  affected  by  the  change.  In  order  to  actually  achieve  the  tantalizing  rewards  from  reuse,
  232. projects can no longer be viewed as independent entities that can be managed without attention
  233. to a wider network of projects that extends not just across organizational subunits but into the
  234. future as well. Champions of reuse who have the power to influence all of the affected entities in
  235. the producer-consumer network are needed to encourage commitment to the program.
  236.  
  237.  
  238. Upper levels of management are more likely to have a strategic, long term view than lower levels of
  239. management who generally have a more focused, tactical orientation.  Long term commitment to
  240. the process is particularly important, because consideration of reuse in the short term may reveal
  241. reuse to be a drain on scarce resources that could prompt management toregard the investments
  242.  
  243.  
  244.  
  245.                                                          Malan- 4
  246.  
  247.  
  248. as sunk costs and bail out of the program, while a longerterm view could have shown the expected
  249. rewards to be high.
  250.  
  251.  
  252. Because management support is so central to the success of the reuse program [4 ], it is vital that
  253. they support reuse when the opportunity cost of not employing systematicreuse is high.  Frequently,
  254. managers prefer to err on the side of conservatismwhen the costs, benefits, payback and risks are
  255. unclear. Therefore, the opportunity cost has to be assessed, and this analysis should encompass a
  256. multi-project, long term view that identifies the reuse costs and benefits,and estimates those that
  257. can be quantified with enough confidence to remain credible. The revenue-side benefits of reuse
  258. (including the impact of earlier time to market, higher quality, and opportunities to attack niche
  259. markets  with  customized  products  [5])  should  not  be  ignored.  Indeed,  the  strategic  benefits  of
  260. reuse, such as reduced time to market or enhancedconsistency in the product line, have generally
  261. been more powerful rallying points for top HP managers than reduced costs [6 ].
  262.  
  263.  
  264.  
  265. 2.2      Integration and Alignment
  266.  
  267.  
  268.  
  269. All members of the organization need to be aware of, and motivated to achieve, the elusive combi-
  270. nation of enhanced quality,shorter development cycles and reduced costs that reuse makes possible.
  271. Development projects can no longer be independently optimized. Also, it is not good enough for
  272. upper management to issue reuse mandates without getting the other players on board through
  273. changes in organization, performance and incentive systems.  Numerous decisions made at the engi-
  274. neering level affect whether or not systematic reuse will be achieved, and it is vital that they believe
  275. that in the long-run everyone gains from the reuseprogram, and are committed to it. Alternatively,
  276. a "grass roots" effort that does not have management support will not achieve its full potential
  277. for  it  will  not  have  the  upfront investment  or  go-ahead  for  organizational  change  to  enable  full
  278. exploitation of multi-project, long-term reuse opportunities.  The incentive problem at each level
  279. should not be approached in isolation, but rather a system solution should be designed to align
  280. reuse goals with organizational objectives and ensure that they are achieved.
  281.  
  282.  
  283.  
  284. 3       Comparison
  285.  
  286.  
  287.  
  288. Some of the specific issues addressed in the above discussion have been surfaced in previous work.
  289. For  example,  Bollinger  and  Pfleeger's  [7 ]  Cost-Sharing  Domain  Banks,  and  Wolff 's  [8]  royalties
  290. are  intended  to  address  the  problem  of  providing  an  incentive  to  produce  for  reuse  through, in
  291. effect,  transfer prices.  However,  transfer pricing is just one alternative in a range of options for
  292. addressing one dimension of the reuse incentive problem.  Also,most economics of reuse models (e.g.
  293. [9, 10 , 11 ]) do not consider the strategic, or revenue-side, benefits of reuse. As Wentzel [6] points out,
  294. the various levels of management have different perspectives, and consideration of strategic benefits
  295. may be less important in gaining the support of managers with cost center resp onsibility, but vital
  296. to achieving strong backing by higher level management. The organization and it's objectives need
  297. to be understood, and a comprehensive approach to motivating reuse among all relevant players in
  298. the organization needs to be developed.
  299.  
  300.  
  301.  
  302. References
  303.  
  304.  
  305.  
  306.   [1] R. Joos, "So much for motherhood,  apple pie and reuse,"  in Proceedings  of  the  5th  Annual
  307.  
  308.  
  309.  
  310.                                                          Malan- 5
  311.  
  312.  
  313.       Workshop on Software Reuse, ComputerScience Department, University of Maine, 1992.
  314.  
  315.  
  316.   [2] E. J. Joyce, "Reusable software: Passage to productivity?," Datamation, September 1988.
  317.  
  318.  
  319.   [3] T. B. Bollinger and S. L. Pfleeger, "The economics of software  reuse," Tech. Rep. CTC-TR-
  320.       89-014, Contel Technology Center, 1989.
  321.  
  322.  
  323.   [4] M. Griss, "Software reuse:  From library to factory," IBM Systems Journal,  to be published,
  324.       1993.
  325.  
  326.  
  327.   [5] R. A. Malan and K. Wentzel,"Economics of software reuse revisited," in Proceedings of ISS'93,
  328.       UC Irvine, 1993.
  329.  
  330.  
  331.   [6] K. Wentzel, "Software reuse - it's a business," in Proceedings of the 5th Annual Workshop on
  332.       Software Reuse, Computer Science Department, University of Maine, 1992.
  333.  
  334.  
  335.   [7] T.  B.  Bollinger  and  S.  L.  Pfleeger, "Economics  of  software  reuse:  Issues and  alternatives,"
  336.       Information and Software Technology, vol. 32, pp. 643-652, December 1990.
  337.  
  338.  
  339.   [8] F.  Wolff, "Long-term  controlling  of  software  reuse," Information  and  Software  Technology,
  340.       vol. 34, pp. 178-188, March 1992.
  341.  
  342.  
  343.   [9] B. H. Barnes and T. B. Bollinger, "Making reuse cost-effective,"IEEE Software, vol. 8, pp. 13-
  344.       24, January 1991.
  345.  
  346.  
  347. [10]  J. E. G. Jr. and R. D. Cruickshank, "Ageneral economics model of software reuse," in Proceed-
  348.       ings of the 14th International Conference on Software Engineering, pp. 327-337, May 1992.
  349.  
  350.  
  351. [11]  J. S. Poulin and J. M. Caruso, "A reusemetrics and return on investment model," in Proceed-
  352.       ings of the Second International Workshop of Software Reusability (IWSR-2), 1993.
  353.  
  354.  
  355.  
  356. 4      Biography
  357.  
  358.  
  359.  
  360. Ruth Malan is participating in Hewlett-Packard's research internship program,  working in the
  361. Software Reuse Department at Hewlett-Packard Laboratories for the Summer. Her interests span
  362. the  business  aspects  of  software  reuse, including  business  opportunity  assessment, reuse  cost  -
  363. benefit analysis and business metrics; reuse incentives, funding models and performance measures;
  364. and reuse asset management and portfolio planning. She received an MBA from Virginia Tech in
  365. 1990, and an M.S. in Operations Research from Stanford University in June, 1993.
  366.  
  367.  
  368.  
  369.                                                          Malan- 6
  370.