Sixteen Questions About Software Reuse William B. Frakes and Christopher J. Fox Communications of the ACM

Software reuse the use of existing software knowledge and artefacts to build new software artefacts sometimes confused with porting –reuse is using an asset in different systems –porting is moving a system across environments and platforms

The survey Surveyed: –software engineers, managers, educators, and other in the software development and research community About: –attitudes, beliefs, and practices in reusing code and other lifecycle objects Response from –113 people from 29 organizations (28 US and one European) –fairly representative of experienced software engineers or managers at high technology companies

16 questions The survey is used to answer 16 questions commonly asked by organizations attempting to implement systematic reuse. The answers to these questions are often taken for granted in the software community but without empirical verification This article uses empirical data from a survey to answer these questions

Q1: How widely reused are common assets? Are reusable assets actually used, and are they found valuable? Answer: yes and no. –Some assets are widely used (e.g.. UNIX tools) and perceived to be valuable, others are not used by many and are not perceived to be valuable (e.g.. Cosmic collection form NASA) Possible reasons: –lack of information and education –anecdotal evidence suggest that relevant functionality is an important factor

Q2: Does programming language affect reuse? Does certain programming languages provide better reuse support (e.g.. by supporting abstractions, inheritance, strong typing) The data of the survey shows the correlation of 11 languages and the level of organizational code reuse. Findings: –languages usually thought to promote reuse show small correlation (e.g.. ADA and C++) –Higher level languages are no more strongly correlated with code reuse than is assembly language Conclusion: –Choice of programming language does not affect code reuse levels –To increase reuse the focus should be on other factors

Q3: Do CASE tools promote reuse? Many organizations regard CASE tools as a way to improve reuse The majority (75%) does not agree that CASE tools have promoted reuse No significant correlation between the respondents degree of belief in that CASE tools promote reuse and the percentage of actual reuse. Conclusion: –CASE tools are yet not effective in promoting reuse –Reasons: CASE tools may not be used CASE tools may not be used correctly CASE tools may not promote reuse

Q4: Do developers prefer to build from scratch or to reuse? NIH (Not Invented Here) syndrome Statement used in the survey: –”It’s more fun to write my own software than to reuse” Most respondent do not have the NIH syndrome (72%) Conclusion: –Most developers prefer to reuse rather than to build from scratch Contradicts conventional assumptions, but is in agreement with other findings

Q5: Does perceived economic feasibility influence reuse? Reuse may not be done if it is not believed to be economically feasible. Levels of individual and organizational code reuse is compared with respondents belief in the economic feasibility of reuse Clear trend towards higher reuse as belief in economic feasibility increases This trend is verified by correlating code reuse with belief in the economic viability of reuse. Conclusion: –perceived economic feasibility influences reuse –important to convince software engineers about the economic feasibility of reuse

Q6: Does reuse education influence reuse? Comparing education in software reuse (at school) with individual levels of reuse shows that education in reuse does affect code and design reuse –Few respondents (17%) had been educated about reuse in school A similar comparison but with education by organization in software reuse, shows the same. –Corporate reuse education is also rare (19%) Conclusion: –Education in school and at work improves reuse and is a necessary part of a reuse program

Q7: Does software engineering experience influence reuse? General assumption that experienced software engineers are better practitioners The survey shows no significant correlations between engineering experience and personal level of reuse. Conclusion: –Software engineering experience has no effect on reuse of lifecycle objects –Maybe caused by historical lack of training in reuse

Q8: Do recognition rewards increase reuse? Reuse incentives are considered to be necessary catalysts for reuse. –recognition rewards and cash rewards Respondents say that rewards are rare –no cash bonuses –only a few with other recognition Comparing levels of organizational code reuse between the two groups ”rec. rewards” and ”no rewards” show no significant differences Similar findings for individual reuse The findings contradict the common belief that recognition is a sufficient reward for reuse. It may be that only monetary rewards are sufficient rewards

Q9: Does a common software process promote reuse? Respondents generally do not agree that a common software process have promoted reuse across projects This might mean: –no defined common process –the process has failed to support reuse The correlations between the degree of agreement with the statement and the organizational reuse shows –moderate correlation for designs, test plans, and test cases –weak correlations for requirements, code, and user documentation Conclusion –A defined software process that promotes reuse does affect software reuse levels –Gains in process maturity can translate into gains in software reuse

Q10: Do legal problems inhibit reuse? Legal issues e.g.. regarding contracting, ownership are still unresolved Are thought to be a serious impediment to reuse Most respondents (68%) report that legal problems do not appear to be an impediment No significant correlation between levels of reuse and reported inhibition by legal problems. Maybe caused by reuse within organization

Q11: Does having a reuse repository improve code reuse A reuse repository is a searchable collection of reusable assets. Slightly higher median for reuse levels for organizations with a repository Not statistically significant Conclusion –Having a reuse repository does not improve reuse –A repository should not be the focus for organizations trying to improve systematic reuse

Q12: Is reuse more common in certain industries? Respondents were asked to classify their company or business Significant differences in reuse between different industries –higher level for telecommunication –lower level for aerospace industries Reasons not currently known Industries with low reuse might benefit from studying and adopting reuse practice in industries that lead in software reuse

Q13: Are company division, or project sizes predictive of organizational reuse? Small organizations: –Is systematic reuse a realistic goal given the the scope of their domain and limited resources? Large organizations: –Instituting systematic reuse may be unrealistic because of the large investment and time required No significant correlation were found between organizational size and reuse levels Conclusion: –Company, division, and project size are not predictive of reuse levels –Organizations of any size may succeed to institute systematic reuse

Q14: Are quality concerns inhibiting reuse? The distrust of assets developed ”outside” is another aspect of NIH No correlation between: –”software developed elsewhere meets our standards” –”what percentage of the parts you reuse are form external sources” Experience in quality of reusable software have generally been favourable (69% agreement) No correlation between personal reuse level and experience in quality of external software Conclusion –Satisfaction with quality does not influence reuse levels –Does NOT mean that quality is unimportant

Q15: Are organizations measuring reuse, quality, and productivity?? Measuring reuse is important to determine success of the reuse program Few organizations are currently measuring reuse (at most 25%) Quality is more widely measured (42%) Productivity measurement is relatively rare (32%) Conclusion: –Most organizations do not measure reuse levels, quality, and productivity –These organizations cannot properly manage their software processes and products, including reuse

Q16: Does reuse measurement influence reuse? Measuring an activity will tend to increase it. Comparing median level of software reuse for organizations that are or are not measuring reuse. The study shows no correlation Conclusion: –Organizations that measure reuse do not use these measurements to improve reuse levels.

How to improve reuse To improve systematic reuse concentrate on: –education about reuse –developers understanding on the economic feasibility of reuse –instituting a common development process –make high quality assets available to developers