Scrapheap Software Development - Lessons from an Experiment on Opportunistic Reuse

Uploaded on

A set of 10 guidelines for opportunistic software reuse is based on observations of nine systems developed entirely with “scraps” of functionality scavenged from abandoned projects.

A set of 10 guidelines for opportunistic software reuse is based on observations of nine systems developed entirely with “scraps” of functionality scavenged from abandoned projects.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. focus FEATURE: SOFTWARE REUSE Scrapheap functionality scavenged from aban- doned projects. 2,3 Unlike development approaches based on systematic reuse Software (see the “Related Work in Software Reuse” sidebar), scrapheap develop- ment places the burden of identify- Development: ing reusable assets on the developer. However, gauging a component’s prac- ticability in different development contexts can be difficult. Even if devel- Lessons from opers can identify reuse opportunities, there are no guidelines or safeguards an Experiment on available to inform their development decisions. To explore these issues, we devised Opportunistic Reuse studies to investigate how developers apply opportunistic reuse in a scrap- heap setting. (The work we describe here extends a short study published Gerald Kotonya, Simon Lock, and John Mariani, Lancaster University earlier. 3) We were inspired by a pop- ular television series that builds ma- chines and devices from discarded me- // A set of 10 guidelines for opportunistic software chanical parts. We aimed to determine scrapheap factors that affect successful reuse is based on observations of nine systems reuse and to derive a set of scrapheap developed entirely with “scraps” of functionality development guidelines. In particu- scavenged from abandoned projects. // lar, we wished to explore the qualities to look for in selecting reusable scrap components. The Scrapheap Development Study To make the study interesting and compelling for the participants, we de- signed it as a competition. The Scrap- heap Software Challenge tasked com- peting teams to build a system fromEVERY YEAR, MORE than US$5 bil- ware artifacts. If we can fi nd efficient scrap software and hardware compo-lion worth of software projects are can- ways to salvage and reuse these com- nents that achieved a particular high-celled or abandoned worldwide.1 Many ponents, we might also recover some level functional goal within a con-of these projects are dropped not be- of the original investment and provide strained time frame. The developmentcause their software failed but because a rapid, low-cost means to develop new teams consisted of academic staff andthe original project aims and assump- products. students—all experienced developers—tions changed. When cancellations oc- Scrapheap software development from our computing department. Teamcur after significant development, they is a form of opportunistic reuse that members knew each other well beforelock in potentially useful, reusable soft- composes systems from “scraps” of the competition began, which proved68 I E E E S O F T W A R E | P U B L I S H E D B Y T H E I E E E C O M P U T E R S O C I E T Y 0 74 0 -74 5 9 / 11 / $ 2 6 . 0 0 © 2 0 11 I E E E
  • 2. essential given the short challenge gain a broad understanding of the note- heap development depends on know-deadlines. worthy issues. ing what component features and prop- Each team included four developers erties are broken or inappropriate inand represented a major research area Team Knowledge the new context. A component withof our department: mobile computing, A team’s combined knowledge proved problems is fine, as long as develop-ubiquitous computing, and human- crucial to success. Scrapheap develop- ers know what the problems are andcomputer interaction. We developed ment requires knowing what scrap is how to avoid them. For example, oneone challenge for each area, and thethree teams competed in all three chal-lenges on three different days (with a A team’s combined knowledgeweek in between each challenge to let proved crucial to success.the teams recover). We revealed thechallenge objective at 8:00 a.m. on theday of competition, and the teams had available, where to obtain it, and how challenge solution selected a camerauntil 5:30 p.m. to build a system from to render it useful to the current proj- -calibration scrap that had been onlyscrap components that would achieve ect. Potential knowledge sources in- partially built in a previous project andthe stated objective. At 5:30 p.m., we clude previous project experience of proved difficult to use in the competi-brought all the teams back together for individuals, a team, or an organization tion system.demonstrations. as well as experience within and across A panel of judges scored the systems practice communities and domains. Component Availabilityon the basis of functional and non- Successful challenge teams used Having to build systems from only cur-functional properties that included us- all these sources: their own experi- rently available scrap components canability, scalability, novelty, creativity, ences, discussions with other members lead to inefficient communication andand product aesthetics. The team with of their research groups, and reports control. During the study, we observedthe highest overall score won the chal- from research and development com- this to be much truer in scrapheap de-lenge, and the team with the most wins munities in general. Time and again, velopment than in more traditionalat the end of the challenge won the developers reused “favorite” compo- forms of opportunistic reuse. We attri-competition. nents that were familiar and trusted. bute the difference to the quality and Throughout the challenges, we cap- In some cases, they were aware of more range of available components and thetured a photographic record of the appropriate components but not famil- limited time the competition allowedevent. Additionally, the challenge or- iar with them. In other cases, the time for component identification and reuse.ganizers moved freely around the chal- constraint prevented them from consid- For example, one system had tolenge area, querying team members ering more appropriate components. transfer an image captured on one com-to capture their aims, strategies, deci- This led to an unexpected phenome- puter to a different computer for pro-sions, successes, and failures. The raw non that we also observed during chal- cessing before returning it to the origi-data captured from these activities sup- lenges—namely, a unique bottom-up, nal computer for use. This was becauseported a full, detailed study. Undertak- technology-driven development style. no single available component provideding any similar analysis “in the wild,” Scrapheap development combines this enough processing capability to com-without benefit of the challenge’s con- development style with the more tradi- plete the operation on its own.strained space and time, would have tional top-down goal- or requirements- Another team used a discarded key-been difficult, if not impossible. driven approaches. logging system to determine numerous “The Scrapheap Software Chal- Another feature of the develop- distributed users’ keyboard activity.lenge” sidebar summarizes the compe- ment was the phenomenon of “cham- The team had to use glue code to fi ltertition assignments and solutions. pions”—that is, team members who the data from the existing system be- promoted the use of particular compo- cause they required only a small sub-Study Observations nents to fulfi ll key system requirements. set of its functionality. However, theThe raw observation data captured Champions would make the case for key logger was a heavyweight serverduring the study gave us considerable a particular component and, in some running on each user’s computer,insight into scrapheap system develop- cases, argue with other team members making solution particularly ineffi -ment. We clustered unique and interest- who opposed the suggestion. cient for the problem of monitoringing phenomena into three key areas to As with most forms of reuse, scrap- user activity. M A R C H /A P R I L 2 0 1 1 | IEEE S O F T W A R E 69
  • 3. FEATURE: SOFTWARE REUSE RELATED WORK IN SOFTWARE REUSE The earliest association of software engineering with reuse dates proposed various strategies to improve software reuse within back to 1968, when Douglas McIlory suggested that the software organizations,9 we’re unaware of experiments investigating the industry should be based on reusable components.1 Two other practicability of scrapheap software development. An industry significant milestones were in 1976, when David Parnas proposed study by Emmanuel Henry and Benoît Faller showed how prag- the notion of program families,2 and 1984, when James Neigh- matic opportunistic reuse achieved far-reaching success.10 In bours proposed the concepts of domain and domain analysis.3 results from two large industry projects, reuse across projects These two ideas began the systematization of software product- and the organization improved time to market, productivity, and line engineering. software quality. Today, software reuse is a major research field, encompassing Our study shows the viability of scrapheap development reuse libraries, domain engineering methods, tools, design reuse, alongside traditional software development. However, develop- design patterns, domain-specific software architecture, com- ers need to know when and how to apply it. A major outcome of ponentry, software services, application generators, measure- our study is a set of guidelines aimed at helping them assess the ment, and experimentation. Two recent surveys on the status and potential success of using particular scrap components. future of software reuse—one by William Frakes and Kyo Kang,4 the other by Sajjan Shiva and Lubna Shala5 —identified several research challenges in the field. These surveys provide important References 1. M.D. McIlroy, “Mass Produced Software Components,” Proc. NATO insights into reuse advances and problems, but they ignore the Software Eng. Conf., Springer, 1968, pp. 138–155. important role of opportunistic reuse in software development.6–8 2. D.L. Parnas, “On the Design and Development of Program Families,” Among the challenges that Frakes and Kang identify is the IEEE Trans. Software Eng., vol. 2, no. 1, 1976, pp. 1–9. difficulty of sustaining reuse on a long-term basis within orga- 3. J.M. Neighbours, “The Draco Approach to Constructing Software from Reusable Components,” IEEE Trans. Software Eng., vol. 10, no. 5, 1984, nizations.4 They suggest better links between reuse and domain pp. 564–574. engineering as a way to address this problem. In our view, aug- 4. W.B. Frakes and K. Kang, “Software Reuse Research: Status and Future,” IEEE Trans. Software Eng., vol. 31, no. 7, 2005, pp. 529–536. menting this approach with one based on opportunistic reuse 5. S.G. Shiva and L.A. Shala, “Software Reuse: Research and Practice,” would give software developers the flexibility to rapidly “mash Proc. 4th IEEE Conf. Information Technology (ITNG 07), IEEE CS Press, up” and try “what if” application ideas. Opportunistic reuse cor- 2007, pp. 603–609. relates with the way developers work intuitively, so it supports 6. C. Ncube, P. Oberndorf, and A.W. Kark, “Opportunistic Software Sys- tems Development,” IEEE Software, vol. 25, no. 6, 2008, pp. 38–41. enhanced reuse within an organization without forcing developers 7. S. Jensen, S. Brinkkemper, and I. Hunink, “Pragmatic and Opportunistic to adopt only new methods. Reuse in Innovative Start-up Companies,” IEEE Software, vol. 25, no. 6, 2008, pp. 42–49. Reuse-driven development requires considerable time and ef- 8. A. Sen, “The Role of Opportunism in the Software Design Reuse Pro- fort to be successful, which have been barriers to small organiza- cess,” IEEE Trans. Software Eng., vol. 23, no. 7, 1997, pp. 418–436. tions. In contrast, opportunistic reuse fits development environ- 9. M. Morisio M. Ezran, and C. Tully, “Success and Failure Factors in ments that have tight deadlines and limited resources.5 Software Reuse,” IEEE Trans. Software Eng., vol. 28, no. 4, 2002, pp. 340–357. The surveys also highlight the need for more empirical work 10. E. Henry and B. Faller, “Large-Scale Industrial Reuse to Reduce Time on reuse and domain engineering. Although researchers have and Cycle Time,” IEEE Software, vol. 12, no. 5, 1995, pp. 47–53.Control Constructs the difficulties of achieving component data transfer and control betweenBecause of time constraints, the teams interoperability gave priority to prac- applications.couldn’t reengineer components before ticality over good design. The compe-using them and instead had to treat tition systems were functional but not The teams also converted softwarethem as black boxes. However, the particularly well designed. Within the components into rudimentary Webtime spent developing the glue to bind study, the constructs took the form of services and hardware components,components and make them interoper- which they then redeployed and madeate was significant. Scrapheap compo- • shell/batch scripts, available for reuse in the scrapheapnents are seldom intended for reuse, so • pipes between pieces of software, challenge. They used multiple ma-they’re seldom amenable to integration • “exec” calls from programs to the chines to host the different compo-with other components. operating system, nents, resulting in large, coarse-gained Each team tended to use a small set • network sockets to build rudimen- distributed systems. The differentof simple, well-understood glue and tary servers, and pieces of glue code holding the solutionother binding constructs. However, • operating system clipboards for systems together had to perform vari-70 I E E E S O F T W A R E | W W W. C O M P U T E R . O R G / S O F T W A R E
  • 4. ous data conversions for the scrap com- faults is essential. However, a source’s nent property, but developers must beponents to interoperate. These con- type and nature will affect the speed and careful not to overlook the importanceversions included data filtering, data significance of information that develop- of coherence. A component’s coher-combination, translation, and compi- ers can derive from it. For example, per- ence will affect the efficiency of bothlation as well as extrapolation, estima- sonal knowledge of a component is likely the development process and the finaltion, and randomization. to provide faster access to rich informa- product. As much as possible, com- Because the system components tion than the relatively slower, more dif- ponents should have a clear respon-were developed independently of each ficult process of digesting knowledge de- sibility and be capable of fully dis-other, they tended to be loosely cou- rived from a research community. charging the associated tasks. If not,pled and highly cohesive. The desirable a particular system functionality willresult, although produced unintention- 3. Don’t underestimate require multiple components—and allally, was systems that were amena- the importance of project knowledge the communication, control, and datable to change and evolution. Compo- First-hand experience of how a previous mechanisms they involve.nents could be unplugged and replaced project used a component is importantwithout affecting other components. for its effective reuse. An understand- 7. Consider whenChange rarely propagated between ing of how previous use contexts com- the component was scrappedcomponents, so its “ripple effect” was pare with the current one is essential. Scrap components are distinguishedminimal. from other reusable components in that, 4. Take into account at some stage of their development, theyGuidelines for supported control structures were discarded. A component’s matu-Using Scrap Components The complexity of the glue code needed rity when it was discarded will affect itsBy clustering our observations, we ab- to control and communicate with a utility. For example, it might not havestracted a set of guidelines for scrap­ component will affect how easily it can been fully tested or adequately docu-heap development. These guidelines be reused. The control constructs sup- mented. However, if it was scrappedpay particular attention to new in- ported by scrap components are often after a useful lifespan, the likelihood issights and fresh perspectives revealed limited, which can force developers to greater that it will behave as specified.during the scrapheap challenges. Westructured the guidelines to increasetheir relevance to reuse approaches be- It’s often better for developersyond scrapheap development and thusbenefit a wider range of practices. to use familiar but functionally less-than-perfect components.1. Consider all a component’s propertiesFor a scrap component to be useful, itshould provide a subset of the proposed use inefficient appropriative mecha- 8. Consider whysystem’s functionality. However, devel- nisms. The additional complexity will the component was scrappedopers must also consider nonfunctional affect project resources and, possibly, The reason for scrapping a compo-requirements and, furthermore, ensure the system’s operational behavior. nent will influence how easily it canthat the various components can achieve be reused. Clearly, if it was scrappedsuitable quality and dependability lev- 5. Don’t ignore the complexity because it was faulty, reusing it in an-els when they’re combined. Addressing of data translation other system could pose problems.these issues often makes it better for The conversion and translation complex- On the other hand, if a componentdevelopers to use familiar but function- ity required to pass data between com- was scrapped because its system wasally less-than-perfect components rather ponents has a major impact on the final replaced—for example, by a systemthan unfamiliar components that ap- product’s quality. Developers must con- with enhanced functionality—reuse ispear to provide ideal functionality. sider the system’s overall data flow, in- likely to be more straightforward. cluding its implications for the complex-2. Take into account ity of glue code and control mechanisms. 9. Don’t ignore residual functionalitycomponent knowledge sources Unused component functionality can ad-Access to detailed information about a 6. Take into account coherence versely affect a system’s performance andscrap component’s behavior and known Completeness is a desirable compo- reliability, yet it’s often ignored when se- M A R C H /A P R I L 2 0 1 1 | IEEE S O F T W A R E  71
  • 5. FEATURE: SOFTWARE REUSE THE SCRAPHEAP SOFTWARE CHALLENGE The teams provided their own scrapheap of software and hard- In addition to basic system functioning, the solutions were ware components from previously discarded systems, abandoned scored for how well they addressed projects that never reached completion, and works in progress • architectural design and scalability, as well as functionality from currently operational systems. They • software engineering practices, used a range of programming languages for gluing the compo- • technical achievement, and nents together, including C, Flash, Java, PHP, shell scripts, and • usability. DOS batch commands. Table A lists some of the components that ended up in the The teams produced three solutions. challenge solutions. A key to success was the team members’ familiarity with Electronic Spray Can the scrapheap from having worked on projects that generated From a programmable intelligent computer for recording audio, the scrap in the first place. However, the functionality was of- one team built an electronic “spray can” and integrated it with a ten spread across several modules, and the teams had to find, set of audio graffiti tags in the environment. The tags sensed the retrieve, and adapt the required functionality in a form that the spray can’s proximity via infrared and notified it of their location. challenge applications could use. Users could listen to any audio graffiti associated with a tag In some cases, teams required components that weren’t avail- or add their own audio for others to hear later (see Figure A1). able in the scrapheap and had to be acquired from other research groups. In these situations, they had to know what components Vision-Based Scene Recognition might be available and who might be able to give them access. A vision-based scene-recognition system used a portable web- We wrote the three high-level, open-ended challenges to give cam to determine the user’s current location. A color-spectrum all teams an equal opportunity to win, regardless of different dis- profiling tool distinguished between different scenes. Users could ciplines, experience, and backgrounds among members. The var- listen to or record audio graffiti associated with a particular loca- ied solutions reflected differences not only in team backgrounds tion. A central server stored the location and audio data. but also in the mix of software and hardware components they used. Wi-Fi Location Sensing A mobile computing solution used distance from Wi-Fi hotspots CHALLENGE 1—MOBILE COMPUTING (determined by signal strength patterns) for location sensing. It The teams had to construct a mobile system to facilitate audio stored audio data on several different media servers, depending graffiti—specifically, the system would let users associate au- on the server proximity to the graffitied location. dio with particular locations or regions in geographical space. It would also let them browse community airwaves by wander- CHALLENGE 2—UBIQUITOUS COMPUTING ing through physical space. The implementations had to include In this challenge, the teams had to create a system that could location-tracking for both indoor and outdoor locations. sense a visitor’s presence and take this forward in some way for Components used by the TABLE A Scrapheap Software Challenge teams. Hardware Software Programmable intelligent computers Generic image-processing tools Actuators and sensor boards Computer vision systems Cannibalized hardware devices Image capture software LCD projectors Instant messenger prototypes Everyday household artifacts Image profiling tools Webcams Key-logging software72 I E E E S O F T W A R E | W W W. C O M P U T E R . O R G / S O F T W A R E
  • 6. future presentation. ing to look at as a work of art and the embodiment of some- In addition, teams had to ensure that the system was thing about the work done in the building. At least some of the information presented was to be obscure, so that either someone • minimally disruptive to the spaces in which it was embedded, needed to explain it or a viewer could figure it out only by watch- • robust enough to continue operation for a reasonable period ing carefully for a while. of time, Individual teams could choose the information source and • scalable to large numbers of users, and method of obtaining it as well as the representation processes • capable of achieving an acceptable level of usability. and form. However, a core requirement was to present data from The aim wasn’t to establish contact with earlier visitors but to more than one source. give visitors a sense that others had been there. The system had to somehow capture an aspect of previous visitors’ behavior. Wizard’s Hat An illuminated robotic hat moved physically to represent activity Augmented Coffee Table in the building (see Figure A4). Data sources that fed the actu- A table graphically “remembered” the objects placed on top of it ated hat were noise and motion sensors that could be distributed or moved across it (see Figure A2). The system used a camera around key spaces in the building. to record new objects on the table, a layered history of previous table images, an image-addition tool to produce a composite im- Emotional Mannequin age, and a top-down projector to overlay the historical image onto A life-sized mannequin displayed the collective emotional state of the table (see Figure A3). all the building’s residents. The system collected emotional-state data by aggregating status indicators of users’ instant messenger Weight-Sensor-Augmented Floor applications. Emotional states were represented in expressions Flooring recorded and preserved people’s footprints as they that were projected on the blank white face of the mannequin. walked across it. The presentation took the form of a grid, with each cell’s color representing the number of footfalls within that “Jacob’s Ladder” Sculpture area. The projected results appeared on the floor. A conical structured served as the display medium for projected sparks that represented activity in the building. Different spark Augmented Sofa colors represented different activities, and the number of sparks A cushion sensor detected the presence of people on a sofa. The quantified it. Data sources included documents being printed, the system maintained a record of the pattern of people sitting over a load on the departmental Web proxy, and keyboard users’ key- period of time and represented it on a nearby screen in the form stroke rates. of elf-like graphical characters. CHALLENGE 3— FIGURE A. Example products from the Scrapheap Challenge: HUMAN-COMPUTER INTERACTION (1) an augmented spray can, (2) and (3) a “Kirlian photograph” The teams had to create a piece of dynamic corporate art for the coffee table, and (4) an activity hat. These systems represent the computing department’s entrance foyer. The artifact had to react three research areas in the competition: mobile computing, in some way to activity in the building. It had to be both interest- ubiquitous computing, and human-computer interaction. Play/record buttons IR transmitter (1) (2) (3) (4) M A R C H /A P R I L 2 0 1 1 | IEEE S O F T W A R E  73
  • 7. FEATURE: SOFTWARE REUSEABOUT THE AUTHORS GERALD KOTONYA is a senior lecturer in software engineering at in controlled situations. The case stud- Lancaster University. His research interests include software architec- ies obviously differ from scrapheap de- ture and service-oriented and component-based software engineering. velopment as it’s practiced in the real He’s particularly interested in novel ways of architecting, visualizing, and evolving self-managing hybrid service-oriented systems. Kotonya world—for example, in terms of project has a PhD in computer science from Lancaster University. He’s a char- duration, specific requirements, team tered engineer and a member of the IEEE Computer Society. Contact size, and system reliability. him at However, many similarities make our fi ndings useful to the research and SIMON LOCK is a lecturer in computing at Lancaster University practice of scrapheap development and and director of BigDog Interactive, a company that develops rapid- opportunistic software reuse in gen- prototype, interactive digital installations. His software engineering eral. Our case studies and real-world interests focus on requirements engineering, design-decision-support tools, pattern languages for technology reuse, and domain modeling for development both face severe time pres- process improvement and multidisciplinary collaboration support. Lock sures, limited resources, incomplete has a PhD in computer science from Lancaster University. Contact him knowledge of component availability at and features, uncertainty as to the suit- ability of initial designs, and poten- JOHN MARIANI is a senior lecturer in computing at Lancaster tial mismatches between system goals University. His research interests include software reuse, ethnography- and available components. The guide- assisted software design, and information visualization—primarily lines represent observations based on to provide new tools for workers in information-heavy environments. Mariani received a PhD in computer science from the University of experiments that confi rm previously Strathclyde, Glasgow. He’s a chartered engineer and a member of the reported success factors for ad hoc re- ACM, the British Computer Society, and the Institution of Engineering use. Although they can’t guarantee suc- and Technology. Contact him at cess, they do offer insight into issues that can make the difference between success and failure. Keeping them in mind during system design can make lecting reuse components. Residual func- the selection of scrap components and tionality increases a system’s footprint, the production of glue code less time- making its operation less efficient and its consuming and more efficient and im- potential for hidden faults greater. prove the fi nal system’s higher quality and performance. 10. Reflect on overall dependability Components differ in how easy they are to understand and in how predictable and trustworthy they are. Developers should consider to what extent a com- Acknowledgments ponent’s functioning is deterministic We thank all the people involved in the Scrapheap Challenge event, from the or- and reliable for a range of inputs and ganizers, judges, and competitors to the NEXT ISSUE: reuse contexts. They should examine observers. quality and dependability issues that go beyond simple functionality. Is it clear from a component’s documenta- References Software tion and a developer’s experience with 1. R.N. Charette, “Why Software Fails,” IEEE Spectrum, vol. 42, no. 9, 2005, pp. 42–49. it how it might behave in a new applica- Components tion context? If this isn’t the case, reus- 2. C. Ncube, P. Oberndorf, and A.W. Kark, “Opportunistic Software Systems Develop- beyond ing it can prove difficult. ment,” IEEE Software, vol. 25, no. 6, 2008, pp. 38–41. Software W 3. G. Kotonya, S. Lock, and J. Mariani, “Scrap- heap Challenge: A Study of Developing Programming e derived these guidelines Systems from Scrap Components,” Proc. 11th Int’l Symp. Component-Based Software Eng. from our interpretation (CBSE 08), LNCS 5282, Springer, 2008, pp. of one-day case studies 302–309.74 I E E E S O F T W A R E | W W W. C O M P U T E R . O R G / S O F T W A R E
  • 8. This article was featured in For access to more content from the IEEE Computer Society, see articles, podcasts, and more.