Every method for developing software is a prescriptive model. Applying a deconstructionist analysis to methods reveals that there are two texts, or sets of assumptions and ideals: a set that is privileged by the method and a second set that is left out, or marginalized by the method. We apply this analytical lens to software reuse, a technique in software development that seeks to expedite one's own project by using programming artifacts created by others. By analyzing the methods prescribed by Component-Based Software Engineering (CBSE), we arrive at two texts: Methodical CBSE and Amethodical Remixing. Empirical data from four studies on code search on the web draws attention to four key points of tension: status of component boundaries; provenance of source code; planning and process; and evaluation criteria for candidate code. We conclude the paper with a discussion of the implications of this work for the limits of methods, structure of organizations that reuse software, and the design of search engines for source code.

Software developers search the Web for various kinds of source code for diverse reasons. In a previous study, we found that searches varied along two dimensions: the size of the search target (e.g., block, subsystem, or system) and the motivation for the search (e.g., reference example or as-is reuse). Would each of these kinds of searches require different search technologies? To answer this question, we conducted an experiment with 36 participants to evaluate three diverse approaches (general purpose information retrieval, source code search, and component reuse), as represented by five Web sites (Google, Koders, Krugle, Google Code Search, and SourceForge). The independent variables were search engine, size of search target, and motivation for search. The dependent variable was the participants judgement of the relevance of the first ten hits. We found that it was easier to find reference examples than components for as-is reuse and that participants obtained the best results using a general-purpose information retrieval site. However, we also found an interaction effect: code-specific search engines worked better in searches for subsystems, but Google worked better on searches for blocks. These results can be used to guide the creation of new tools for retrieving source code from the Web.

As software engineering educators, it is important for us to realize the increasing domain-specificity of software, and incorporate these changes in our design of teaching material. Bioinformatics software is an example of immensely complex and critical scientific software and this domain provides an excellent illustration of the role of computing in the life sciences. To study bioinformatics from a software engineering standpoint, we conducted an exploratory survey of bioinformatics developers. The survey had a range of questions about people, processes and products. We learned that practices like extreme programming, requirements engineering and documentation. As software engineering educators, we realized that the survey results had important implications for the education of bioinformatics professionals. We also investigated the current status of software engineering education in bioinformatics, by examining the curricula of more than fifty bioinformatics programs and the contents of over fifteen textbooks. We observed that there was no mention of the role and importance of software engineering practices essential for creating dependable software systems. Based on our findings and existing literature we present a set of recommendations for improving software engineering education in bioinformatics.

Metrics efforts are often impeded by factors such as poor data quality and developer resistance. To better understand and thus to address the developer perspective in a metrics program we undertook a case study at a large multi-national corporation. We identified six projects, and conducted surveys of both project managers and developers. These surveys were based on the metrics acceptance model (MAM) which is a framework (i.e. a model of relationships between factors, operationalized by a survey instrument) for gauging developer opinions toward software metrics. We noticed some interesting differences between developers' and managers' perceptions of metrics. While managers were on the same page as developers when it came to factors such as ease of use of the metrics tool, they over-estimated developers' confidence to report accurate measures. Managers under-estimated developers' beliefs about the usefulness of metrics and about their fear of adverse consequences. These findings suggest that the MAM could provide useful insights to project managers to train and motivate their developers. We also found that the MAM can be an effective diagnostic tool both at an organizational and project level to identify potential impediments in metrics programs.

Software process improvement initiatives such as metrics programs have a high failure rate during their assimilation in a software organization. Social and organizational issues are some of the factors affecting the adoption and acceptance of metrics, and these issues have not been discussed in detail in existing metrics literature. We undertook an interview-based study with the purpose of studying factors that influence the buy-in of metrics. We interviewed 12 members of the metrics team of a large multi-national corporation, with a thriving metrics program. We found that there was some resistance to standardization of corporate metrics processes introduced by the metrics team. This resistance centered on the metrics data collection and reporting processes. One cause of resistance was the presence of sub-cultures and native data collection and reporting processes within organizational units that were independent businesses before they were acquired. Some of the pushback manifested itself through begrudging compliance, and avoidance activities like scripting and gaming of metrics. In this paper, we present the perspectives of developers, managers and upper-level management to emphasize that each stakeholder in the metrics initiative has a valid viewpoint that should be taken into account while implementing a metrics program and that each metrics effort is inextricably enmeshed with the organizational context. We provide actionable recommendations to understand the different perspectives and to adapt the metrics effort accordingly.