90 IEEE SOFTWARE | PUBLISHED BY THE IEEE COMPUTER SOCIETY 0 7 4 0 - 7 4 5 9 / 1 7 / $ 3 3 . 0 0 © 2 0 1 7 I E E E

Editor: Jeffrey C. CarverUniversity of Alabamacarver@cs.ua.edu

PRACTITIONERS’ DIGEST

The Human FactorJeffrey C. Carver, Birgit Penzenstadler, Alexander Serebrenik, and Aiko Yamashita

IN THIS ISSUE, we report on papers from the 39th International Confer-ence on Software Engineering and its collocated events. These papers focus on human factors in software engineering, with the last three deal-ing with open source software. Feed-back and suggestions are welcome. In addition, if you try or adopt any of the practices mentioned in the col-umn, please send Jeffrey Carver and the paper authors a note about your experiences.

Brainstorming and Inclusiveness“From Diversity by Numbers to Diver-sity as Process: Supporting Inclusive-ness in Software Development Teams with Brainstorming,” by Anna Filip-pova and her colleagues, discusses how brainstorming affected the satis-faction of minority developers work-ing in group settings.1 Software devel-opment is inherently collaborative, and its success depends on the ability of every team member to contribute. Unfortunately, minority team mem-bers, such as women, face greater chal-lenges speaking up, and when they do, their input is often overlooked or dis-missed. Brainstorming supports minor-ity team members’ engagement and satisfaction by providing structure for all team members to voice ideas and by encouraging integration of every contribution.

To study brainstorming’s effects, Filippova and her colleagues studied

participants from two hackathons that emphasized diversity and involved par-ticipants who were minorities in terms of gender, race, age, location, educa-tion, and development experience. In both events, participants worked in groups to identify problems and develop solutions. The authors didn’t impose brainstorming concepts on the groups; they used postevent surveys and inter-views to identify groups that had used brainstorming.

The results showed that brain-storming had a direct positive impact on process satisfaction and an indi-rect positive impact on outcome sat-isfaction. These effects were stronger for the minority participants. That is, brainstorming had a more positive effect on minority participants’ sat-isfaction with both their group pro-cesses and outcomes. This research’s results suggest that brainstorming is a practical mechanism for sup-porting inclusion in diverse teams. You can access this paper at bit.ly /PD_Sept_1.

Dealing with Future Privacy Requirements“Privacy Requirements: Present and Future,” by Pauline Anthonysamy and her colleagues, highlights the change in thinking required to handle future privacy requirements.2 We’re mov-ing from a priori scoping of privacy requirements to open, fluid infor-mation flow. This move means that future privacy requirements must cope

PRACTITIONERS’ DIGEST

SEPTEMBER/OCTOBER 2017 | IEEE SOFTWARE 91

with system boundaries that have become more fluid.

Previously, research on privacy requirements focused on the legal aspects of extracting them from legal texts and policies and on veri-fying them through model check-ing and the formalization of regu-latory rules. This approach makes clear what information is protected. However, it’s also restricting and limited in the information it pro-vides because it assumes a static answer (for example, a user saying “I will never give away my Interna-tional Mobile Equipment Identity,” even though some services might require that as a verification mech-anism). In summary, the current focus is system-driven, syntactic, and attribute-driven.

The move toward systems that collaborate more closely with each other will require privacy require-ments to shift to a cross-system (and cross-domain) focus. To properly support this shift, we need transpar-ency, and we need to educate users so that they can make informed deci-sions about the tradeoffs between the gains from sharing information and the loss of privacy. We also need to shift toward a deeper understand-ing of privacy that considers derived attributes and synthetic data (for example, location privacy for mobile devices that takes into account speed and the previous known loca-tion). This paper is a call to action toward cross-domain privacy analy-sis, deep privacy, and user empow-erment. You can access it at bit.ly /PD_Sept_2.

Code Reviews and Social Relationships“Process Aspects and Social Dynam ics of Contemporary Code Review: Insights from Open Source

Development and Industrial Prac-tice,” by Amiangshu Bosu and his colleagues, reports on the ben-efits organizations gain from code reviews, besides improving their software’s quality.3 To identify those benefits, the authors sur-veyed open source developers and Microsoft developers who had participated in 30 or more code reviews.

The code reviews had an impor-tant impact on the social relation-ships in an organization. Specifically, the second most common reason why code reviews were important (behind maintainability issues) was knowl-edge sharing. Respondents also indi-cated that the two most important factors in deciding whether to accept a code review request were the code author’s reputation and the reviewer’s prior relationship with the author. Finally, respondents indicated that the quality of the code under review (good or bad) affected the reviewer’s perception of the code author’s abili-ties and personal characteristics.

Bosu and his colleagues also identify similarities and differences between the open source develop-ers’ and Microsoft developers’ expe-riences. Overall, the two groups of developers gave similar responses regarding how code review affected social relationships, although they emphasized different aspects. The open source developers focused on relationship building, whereas the Microsoft developers focused on knowledge dissemination. You can access this paper at bit.ly/PD_Sept_3 and the corresponding slides at bit .ly/PD_Sept_3a.

Understanding Open Source Licenses“Do Software Developers Under-stand Open Source Licenses?,” by

Daniel Almeida and his colleagues, examines how well developers understood the implications of using various open source licenses, either alone or in combination.4 In response to this paper, Peter Smith, principal software engineer at ACL, told us that “the Internet makes it incred-ibly easy for developers to integrate open source packages into their own software.” The use of such packages requires that organiza-tions understand the licenses that govern components’ use. Because a license’s applicability depends on how a particular component is used, licensing issues can’t be delegated exclusively to managers or legal departments.

In a survey of 375 developers, Almeida and his colleagues posed various hypothetical scenarios (for example, “Can Sue make her appli-cation commercially available under MPL [Mozilla Public License] 2.0 if it makes use of a library distributed under GNU GPL [General Public License] 3.0?”). They then compared the developers’ responses to those of an intellectual-property lawyer who was an expert on open source licenses.

The developers understood the applicability and implications of single licenses, even when used in complex scenarios. Conversely, they had difficulty identifying the cor-rect interactions in scenarios involv-ing multiple licenses. Smith also said that “this [lack of understanding of multiple licenses] is important, especially as I’ve witnessed expen-sive software ‘rewrites’ as compa-nies come to realize their mistake.” So, the need exists for tools that help developers identify license inconsis-tencies and that suggest potential refactorings. You can access this paper at bit.ly/PD_Sept_4.

PRACTITIONERS’ DIGEST

92 IEEE SOFTWARE | W W W.COMPUTER.ORG/SOFT WARE | @IEEESOFT WARE

Managing Docker“An Empirical Analysis of the Docker Container Ecosystem on GitHub,” by Jürgen Cito and his colleagues, presents their analysis of a large sample of projects in the Docker ecosystem.5 The authors aimed to understand the ecosys-tem’s evolution and quality issues and determine guidelines for tool support to improve quality and drive ecosystem change. Docker, which lets developers package an application and its dependences as a self-contained unit, has become the de facto standard for software containerization.

After analyzing more than 70,000 GitHub Dockerfiles, Cito and his colleagues made these observations.

• The Docker images were quite large. By using a heavyweight OS as their base image, most Dockerfiles defeated containerization’s original purpose, which is to lower virtualization’s footprint. Reducing the image size could tremendously affect the build time for continuous integration or deployment in an orchestration system such as Kubernetes.

• Build failures took too long. Approximately one-third of the builds failed, taking an average of 90.5 seconds to notify developers of the failure. Compared with the results for Java projects built on Travis CI, this delay could be problematic if building the Docker image was part of the continuous-deployment or continuous-delivery pipeline.

• Version pinning was prob-lematic. Over 25 percent of

the quality issues arose from missing version information for dependencies.

• Unstructured dependencies drove recurring changes. Most changes in Docker resulted from dependencies that were stored in an unstructured manner.

The authors suggest these rem-edies:

• Reduce the image size by using a lighter-weight OS as the base.

• Integrate quality checks to issue version-pinning warnings as part of the build process.

• Use better abstractions to resolve the intricacies of different pack-age managers.

You can access this paper at bit.ly /PD_Sept_5.

References 1. A. Filippova, E. Trainer, and J.D.

Herbsleb, “From Diversity by Numbers

to Diversity as Process: Supporting

Inclusiveness in Software Development

Teams with Brainstorming,” Proc.

39th Int’l Conf. Software Eng.

(ICSE 17), 2017, pp. 152–163.

2. P. Anthonysamy, A. Rashid, and R.

Chitchyan, “Privacy Requirements:

Present and Future,” Proc. 39th Int’l

Conf. Software Eng.—Software Eng.

in Society Track (ICSE—SEIS), 2017,

pp. 13–22.

3. A. Bosu et al., “Process Aspects and

Social Dynamics of Contemporary

Code Review: Insights from Open

Source Development and Industrial

Practice,” IEEE Trans. Software

Eng., vol. 43, no. 1, 2017,

pp. 56–75.

4. D.A. Almeida et al., “Do Software

Developers Understand Open Source

Licenses?,” Proc. 25th Int’l Conf.

Program Comprehension (ICPC 17),

2017, pp. 1–11.

5. J. Cito et al., “An Empirical Analysis

of the Docker Container Ecosystem

on GitHub,” Proc. 14th Int’l Conf.

Mining Software Repositories

(MSR 17), 2017, pp. 323–333.

JEFFREY C. CARVER is a professor in

the University of Alabama’s Department of

Computer Science. Contact him at carver@

cs.ua.edu.

BIRGIT PENZENSTADLER is an assistant

professor of software engineering at California

State University, Long Beach. Contact her at

birgit.penzenstadler@csulb.edu.

ALEXANDER SEREBRENIK is an associate

professor in Eindhoven University of Technol-

ogy’s Department of Mathematics and Com-

puter Science. Contact him at a.serebrenik@

tue.nl.

AIKO YAMASHITA is a research scientist at

Centrum Wiskunde & Informatica and an adjunct

associate professor at Oslo and Akershus Univer-

sity’s College of Applied Sciences. Contact her

at aiko.fallas@gmail.com.

Read your subscriptions through the myCS publications portal at

http://mycs.computer.org