“AI is going to radically change creative work”, we hear all around us. But what is that creativity that needs to be disrupted? In this talk Felienne Hermans, professor of computer science education at VU Amsterdam, will examine technology’s worldview, one of control and dominance, of measurements and data, and examine how that worldview shapes their understanding of the world and of their software systems.

Two critical and interrelated questions regarding the design and study of programming languages are: 1) What does it mean to design a programming language? and 2) Why does minimal demographic diversity persist in the programming language community? In this paper, we present feminism as a philosophical lens for analyzing the programming languages field in order to help us understand and answer the motivating questions above. By using a feminist lens, we are able to explore how the dominant intellectual and cultural norms have both shaped and constrained programming languages. A key contribution of this analysis is the explanation of how marginalization in the programming language community limits the intellectual and demographic makeup of the field. We see this paper as an invitation to everyone in the programming languages field to deepen our collective understanding of the forces shaping our field. Our goal is to illustrate opportunities for more inclusive practices that will introduce greater diversity to the design of programming languages and the demographic makeup of the programming language community.

From an early age, girls may opt out of Computer Science (CS) for not fitting the CS stereotypes of being male, asocial and technology-oriented. These stereotypes might be strengthened by children's books on programming, but little is known about this. Therefore, this paper explores the gender, social interactions and interests of characters illustrated in ten popular extracurricular Scratch and Python children's books. We found more masculine than feminine characters in all but one book. Furthermore, nearly half of the characters are illustrated alone, and 15% are interacting with computers & robots. Over two-thirds of the characters fit at least one stereotypical trait. With this paper, we aim to create awareness of stereotypes in CS books among creators, publishers and buyers. Making and using more inclusive CS materials will help close the gender gap.

Background and Context. Increasing gender diversity in the field of Computer Science (CS) benefits the economy as well as gender equality. However, several obstacles - including underdeveloped CS interests, lack of programming experience, and a misfit with the stereotypes of computer scientists - prevent women from entering the field. Although these barriers develop from an early age, research focused on children is limited. Furthermore, limited work is done within European countries.

Motivation. Many people interested in learning a programming language choose online courses to develop their skills. The concept of variables is one of the most foundational ones to learn, but can be hard to grasp for novices. Variables are researched, but to our knowledge, few empirical observations on how the concept is taught in practice exist. Objective. We investigate how the concept of variables, and the respective naming practices, are taught in introductory Massive Open Online Courses (MOOCs) teaching programming languages. Methods. We gathered qualitative data related to variables and their naming from 17 MOOCs. Collected data include connections to other programming concepts, formal definitions, used analogies, and presented names. Results. We found that variables are often taught in close connection to data types, expressions, and program execution and are often explained using the 'variable as a box' analogy. The latter finding represents a stronger focus on 'storing values', than on naming, memory, and flexibility. Furthermore, MOOCs are inconsistent when teaching naming practices. Conclusions. We recommend teachers and researchers to pay deliberate attention to the definitions and analogies used to explain the concept of variables as well as to naming practices, and in particular to variable name meaning.

SIGCSE is packed with teaching insights and inspiration. However, we get these insights and inspiration from hearing our colleagues talk about their teaching. Why not watch them teach? This session does exactly that! Six exceptional educators will present innovative content just as they would to their students. The moderator, Colleen Lewis, will describe their pedagogical moves and how they connect to education research. The goal of the session is to inspire SIGCSE attendees by highlighting innovative instruction by exceptional educators. Attendees can adopt the content and/or pedagogical moves from each microteaching example.

Software Engineering and Computer Science (CS) programs often contain several mathematical courses or courses with large mathematics components or dependencies. Study success in those subjects can be influenced by students’ attitudes towards mathematics and their perceptions about their own relation with mathematics. To gain insights into how the mathematics perceptions of computer science students affect their studies, we collected qualitative data from fourteen CS students from two universities in the context of an elective mathematics course. In this qualitative research, we used a triangulation strategy by collecting data from three different sources (interviews, questionnaires, and math-history assignments) to develop a comprehensive understanding of CS students’ mathematics perceptions. The thematic analysis revealed the factors that affect students’ perceptions about mathematics, including various types of prior experiences, their self-efficacy, math anxiety, and motivation sources. The analysis also highlighted that students find mathematics important for skill transfer to specific CS topics and for supporting continuous learning.

Teaching practices play a crucial role in improving students' learning outcomes in mathematics and science. Previous studies have revealed teaching strategies for improving students' programming knowledge and skills in programming education. However, we know relatively little about teachers' use of teaching practices and the factors that may affect teachers' use of them in their programming classrooms. This paper examines teachers' use of teaching practices in their programming classrooms and explores the effect of their background characteristics and self-efficacy. Data are collected from a survey of 164 teachers who taught Scratch programming to students in primary and secondary schools in China. The results reveal that teachers frequently use integrated direct instruction and classroom management strategies for teaching programming with Scratch. We find no significant effect of teachers' background characteristics (gender, subject major, Scratch learning experience, and grade level taught) on their use of integrated direct instruction and classroom management strategies. In addition, there is no significant correlation between teaching experience and teaching practices in terms of integrated direct instruction and classroom management strategies, respectively. When exploring the effect of teachers' self-efficacy on teaching practices in programming classrooms, we find that teachers' self-efficacy is an essential factor that significantly correlates with the application of integrated direct instruction and classroom management strategies. Teachers with high self-efficacy are found to use integrated direct instruction and classroom management strategies more often than teachers with medium and low self-efficacy. These findings lay the groundwork for future research into investigating teaching practices in programming education.

With the growing interest in programming skills in society, programming will inevitably become part of national curricula. The research presented on this poster aims to address programming for everyone and hopes to contribute to the accessibility of programming lessons for both students and teachers with various backgrounds. In order to do so, we approach the learning and teaching of a programming language from a natural language perspective, and in particular, we focus on reading code, including one of the most important programming concepts: variables.

Programming language implementations are often one-size-fits-all. Irrespective of the ethnographic background or proficiency of their users, they offer a single, canonical syntax for all language users. Whereas professional software developers might be willing to learn a programming language all in one go, this might be a significant barrier for non-technical users, such as children who learn to program, or domain experts using domain-specific languages (DSLs). Parser tools, however, do not offer sufficient support for graduality or internationalization, leading (worst case) to maintaining multiple parsers, for each target class of users.

Motivation More and more high schools are teaching programming, and in many cases, teachers teach multiple programming languages to the same group of students. Objectives The goal of this paper is to explore the views of high-school teachers on second and subsequent programming languages, including their motivation for teaching multiple languages, their struggles, and their use of transfer strategies when they teach their second or third programming language. Method The study consists of semi-structured interviews with 23 high-school teachers in two European countries. Results Our findings indicate that school pupils face the same issues as university students when moving from first to subsequent languages. Furthermore, the teachers’ attitudes towards second language learning are highly variable, both positive and negative, with some supportive teaching strategies used, but many less helpful ones in evidence too. Discussion Our findings suggest that the value of second language learning needs to be highlighted in teacher professional development materials more strongly and that teachers might need more support in implementing transfer strategies.

Motivation Only 27% of computer and mathematical scientists in the United States and 18% of IT specialists in Europe are women. The under-representation of women in the field of Computer Science is, among other things, influenced by stereotypes of computer scientists. These stereotypes include being male, asocial and having an (obsessive) interest in computers. Even though stereotypical beliefs can develop at an early age, research on children’s stereotypes of computer scientists is sparse and inconclusive.

In programming education, explicit strategies are gaining traction. The reason for this study was to improve an introductory programming course based on a problem-based methodology, by using more explicit programming strategies. After analysing a previous run of this course for first year undergraduate students, we concluded that such strategies could improve learning transfer for students across the different weeks of the semester. We introduced four instructional strategies to tutors with close to no pedagogical background: explicit tracing, subgoal labeled worked examples, Parsons problems and explicit problem solving. These explicit programming strategies aim to decrease cognitive load. Tutors tested these four strategies in the course.

Competency-based learning has been a successful pedagogical approach for centuries, but only recently has it gained traction within computing education. Building on recent developments in the field, this working group will explore competency-based learning from practical considerations and show how it benefits computing. In particular, the group will identify existing computing competencies and provide a pathway to generate competencies usable in the field. The working group will also investigate appropriate assessment approaches, provide guidelines for evaluating student attainment, and show how accrediting agencies can use these techniques to assess the level of competence reflected in their standards and criteria. Recommendations from the working group report are intended to help practical computing education writ large.

The use of spreadsheets in industry is widespread. It is known that spreadsheets have an average life span of five years, and during this life span, they are used on average by thirteen different persons. Consequently, spreadsheets need maintenance, and knowledge about the spreadsheet needs to be transferred from one user to another. To minimize the risk of introducing new errors, a thorough understanding of the spreadsheet's formulas is needed during maintenance and knowledge transfer tasks.Research on the use of block-based languages has shown that they positively affect the comprehension of program code. We hypothesize that using a block-based representation of a spreadsheet formula will positively affect formula comprehension.Hence, we extended XLBlocks, a block-based formula editor for spreadsheets, with the functionality to generate a block-based representation of an existing formula. We conduct a think-aloud study with twenty-one experienced spreadsheet users from industry and ask them to perform a set of spreadsheet comprehension tasks using XLBlocks. During an interview, we ask them, using the Cognitive Dimensions of Notations framework, to reflect on the use of XLBlocks.We found that participants preferred to use the block-based representation of formulas when analyzing or explaining formulas or to implement non-trivial changes. Named function parameters and the absence of parentheses and commas make functions easier to understand. Furthermore, the visualization enables the user to separate smaller parts in the formula, which improves comprehension. Finally, the possibility to navigate from formula to formula makes it clear how formulas work together and improve the understanding of the spreadsheet as a whole.

Recently the ‘gradual programming’ approach was introduced, which proposes to lower the syntax barrier by starting with a very simple language, and gradually adding both concepts and refining syntax. Hedy is the first language to implement a gradual approach, and this paper presents the first user study on Hedy with 39 children between age 11 and age 14 who followed online lessons for six weeks. Based on lesson observations and a written survey filled out by the participants, we aim to understand the impact of using a gradual language. Our findings show that children appreciate the gradual nature of Hedy, find Hedy easy to learn and especially appreciate the power to control the difficulty of Hedy themselves. They also like and frequently use built-in education features like example code snippets. Challenges of a gradual approach are the fact that commands sometimes change or overlap, and remembering commands and specific syntax remain a challenge. According to the participants, improvements could be made by making Hedy less sensitive to syntax errors, by improving error messages and by localizing keywords to the native language of children.

Prior research has explored potential applications of video games in programming education to elicit computational thinking skills. However, existing approaches are often either too general, not taking into account the diversity of genres and mechanisms between video games, or too narrow, selecting tools that were specifically designed for educational purposes. In this paper we propose a more fundamental approach, defining beneficial connections between individual design patterns present in video games and computational thinking skills. We argue that video games have the capacity to elicit these skills and even to potentially train them. This could be an effective method to solidify a conceptual base which would make programming education more effective.

One of the aspects of programming that learners often struggle with is the syntax of programming languages: remembering the right commands to use and combining those into a working program. Prior research demonstrated that students submit source code with syntax errors in 73% of cases and even the best students do so in 50% of cases. An analysis of 37 million compilations by 250.000 students found that the most common error was a syntax error, which occurred in almost 800.000 compilations. It was also found that Java and Perl are not easier to understand than a programming language with randomly generated keywords, stressing the difficulties that novices face in understanding syntax.

A notional machine is a pedagogic device to assist the understanding of some aspect of programs or programming. It is typically used to support explaining a programming construct, or the user-understandable semantics of a program. For example, a variable is like a box with a label, and assignment copies or moves a value into that box. This working group will capture examples of notional machines from actual pedagogical practice, as expressed in textbooks (or other teaching materials) or used in the classroom. We will interview at least 30 teachers about their experience with, and perceptions of, the use of notional machines in teaching. Using the interviews, we will work on devising and refining a form to characterise essential features of notional machines. We will also attempt to relate them to each other to describe potential learning sequences or progressions. The working group report will contain descriptions of notional machines used at different levels in education, in different countries, by many teachers. Capturing and Characterising Notional Machines Sally Fincher, Johan Jeuring, Craig S Miller Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). ITiCSE 2020,,Trondheim, Norway © 2020 Copyright held by the owner/author(s). 978-1-4503-0000-0/18/06...$15.00 https://doi.org/10.1145/1234567890 The resulting catalogue of notional machines will allow a teacher to select a machine for a particular use, permit comparison between them, and provide a starting point for further categorization and analysis of notional machines. Additionally, we will make more theoretical explorations. We will explore a variety of presentational formats, examining what is necessary and what superfluous; we will look for dimensions of comparison and will examine how notional machines are instantiated across the discipline. We argue that the creation and use of notional machines is potentially a signature pedagogy for computing [1] and that creating and using notional machines represents a certain level of pedagogic sophistication that might be an indicator of pedagogic content knowledge (PCK).

Abstract Open source software projects often use issue repositories, where project contributors submit bug reports. Using these repositories, more bugs in software projects may be identified and fixed. However, the content and therefore quality of bug reports vary. In this study, we aim to understand the significance of different elements in bug reports. We interviewed 35 developers to gain insights into their perceptions on the importance of various contents in bug reports. To assess our findings, we surveyed 305 developers. The results show developers find it highly important that bug reports include crash description, reproducing steps or test cases, and stack traces. Software version, fix suggestions, code snippets, and attached contents have lower importance for software debugging. Furthermore, to evaluate the quality of currently available bug reports, we mined issue repositories of 250 most popular projects on Github. Statistical analysis on the mined issues shows that crash reproducing steps, stack traces, fix suggestions, and user contents, have statistically significant impact on bug resolution times, for ∼70%, ∼76%, ∼55%, and ∼33% of the projects. However, on avarage, over 70% of bug reports lack these elements.

Twitter is one of the most popular social media platforms, with over 320 million active users as of February 2019. Twitter users can enjoy free content delivered by other users whom they actively decide to follow. However, unlike in other areas where Twitter is used passively (e.g., to follow influential figures and/or information agencies), in science it can be used in a much more active, collaborative way: to ask for advice, to form new bonds and scientific collaborations, to announce jobs and find employees, to find new mentors and jobs. This is particularly important in the early stages of a scientific career, during which lack of collaboration or delayed access to information can have the most impact. For these reasons, using Twitter appropriately [1] can be more than just a social media activity; it can be a real career incubator in which researchers can develop their professional circles, launch new research projects and get helped by the community at various stages of the projects. Twitter is a tool that facilitates decentralization in science; you are able to present yourself to the community, to develop your personal brand, to set up a dialogue with people inside and outside your research field and to create or join professional environment in your field without mediators such as your direct boss. This article is written by a group of researchers who have a strong feeling that they have personally benefited from using Twitter, both research-wise and network-wise. We (@DrVeronikaCH, @Felienne, @CaAl, @nbielczyk_neuro, @ionicasmeets) share our personal experience and advice in the form of ten simple rules, and we hope that this material will help a number of researchers who are planning to start their journey on Twitter to take their first steps and advance their careers using Twitter.

Microsoft VBA (Visual Basic for Applications) is a programming language widely used by end-user programmers, often alongside the popular spreadsheet software Excel. Together they form the popular Excel-VBA application ecosystem. Despite being popular, spreadsheets are known to be fault-prone, and to minimize risk of faults in the overall Excel-VBA ecosystem, it is important to support end-user programmers in improving the code quality of their VBA programs also, in addition to improving spreadsheet technology and practices. In traditional software development, automatic code inspection using static analysis tools has been found effective in improving code quality, but the practical relevance of this technique in an end-user development context remains unexplored. With the aim of popularizing it in the end-user community, in this paper we examine the relevance of automatic code inspection in terms of how inspection rules are perceived by VBA programmers. We conduct a qualitative study consisting of interviews with 14 VBA programmers, who share their perceptions about 20 inspection rules that most frequently detected code quality issues in an industrial dataset of 25 VBA applications, obtained from a financial services company. Results show that the 20 studied inspection rules can be grouped into three categories of user perceptions based on the type of issues they warn about: i) 11 rules that warn about serious problems which need fixing, ii) 7 rules that warn about bad practices which do not mandate fixing, and iii) 2 rules that warn about purposeful code elements rather than issues. Based on these perceptions, we conclude that automatic code inspection is considerably relevant in an end-user development context such as VBA. The perceptions also indicate which inspection rules deserve the most attention from interested researchers and tool developers. Lastly, our results also reveal 3 additional issue types that are not covered by the existing inspection rules, and are therefore impetus for creating new rules.

Programming education currently begins at the elementary school age. In this paper we are exploring what affects the learning performance of young students in programming classes. We present the results collected during an eight-week experimental Scratch programming course run in elementary schools. We emphasize factors that have been found to affect learning performance in adult students, including self-efficacy and motivation, and measure how they affect students of this age group. We further explore the students' view of programming as a career path, and measure the effects of the course, their performance, and the stereotypes that they assume for computer scientists. We find that students' intrinsic and extrinsic motivation and previous programming experience are important factors, being strongly correlated with their self-efficacy and their inclination towards a CS career. For female students only, we also find CS career orientation to be strongly correlated with their self-efficacy.

Software testing is an important topic in software engineering education, and yet highly challenging from an educational perspective: students are required to learn several testing techniques, to be able to distinguish the right technique to apply, to evaluate the quality of their test suites, and to write maintainable test code. In this paper, we describe how we have been adding a pragmatic perspective to our software testing course, and explore students' common mistakes, hard topics to learn, favourite learning activities, and challenges they face. To that aim, we analyze the feedback reports that our team of Teaching Assistants gave to the 230 students of our 2016-2017 software testing course at Delft University of Technology. We also survey 84 students and seven of our teaching assistants on their perceptions. Our results help educators not only to propose pragmatic software testing courses in their faculties, but also bring understanding on the challenges that software testing students face when taking software testing courses.

Spreadsheets are frequently used in industry to support critical business decisions. Unfortunately, they also suffer from error-proneness, which sometimes results in costly consequences. Experiments in the field of program education have shown that programmers tend to make fewer errors and can better focus on the logic of a program if they use a block-based language instead of a textual one. We hypothesize that a block-based formula editor could support spreadsheet users in a similar way. Therefore, we develop XLBlocks and conduct a think-aloud study with 13 experienced spreadsheet users from industry. Participants are asked to create and edit several formulas, using our block-based language. We then ask them to evaluate this editor using the Cognitive Dimensions of Notations framework. We found that for all dimensions the block-based formula editor received a better evaluation than the default text-based formula editor.

Programming misconceptions have been a topic of interest in introductory programming education, with a focus on university level students. Nowadays, programming is increasingly taught to younger children in schools, sometimes as part of the curriculum. In this study we aim at exploring what misconceptions are held by younger, school-age children. To this end we design a multiple-choice questionnaire with Scratch programming exercises. The questions represent a selected set of 11 known misconceptions and relate to basic programming concepts. 145 participants aged 7 to 17 years, with an experience in programming, took part in the study. Our results show the top three common misconceptions are the difficulty of understanding the sequentiality of statements, that a variable holds one value at a time, and the interactivity of a program when user input is required. Holding a misconception is influenced by the mathematical effect of numbers, semantic meaning of identifiers and high expectations of what a computer can do.Other insights from the results show that older children answer more questions correctly, especially for the variable and control concepts. Children who program in Scratch only seem to have difficulties in answering the questions correctly compared to children who program in Scratch and another language. Our findings suggest that work should focus on identifying Scratch-induced misconceptions, and develop intervention methods to counter those misconceptions as early as possible. Finally, for children who start learning programming with Scratch, materials should be more concept-rich and include diverse exercises for each concept.

The use of spreadsheets in industry is widespread and the information that they provide is often used for decisions. Research has shown that spreadsheets are error-prone, leading to the risk that decisions are made on incorrect information. Software Evolution is a well-researched topic and the results have proven to support developers in creating better software. Could this also be applied to spreadsheets? Unfortunately, the research on spreadsheet evolution is still limited. Therefore, the aim of this paper is to obtain a better understanding of how spreadsheets evolve over time and if the results of such a study provide similar benefits for spreadsheets as it does for source code. In this study, we cooperated with Alliander, a large energy network company in the Netherlands. We conducted two case studies on two different set of spreadsheets that both were already maintained for a period of three years. To have a better understanding of the spreadsheets itself and the context in which they evolved, we also interviewed the creators of the spreadsheets. We focus on the changes that are made over time in the formulas. Changes in these formulas change the behavior of the spreadsheet and could possibly introduce errors. To effectively analyze these changes we developed an algorithm that is able to detect and visualize these changes. Results indicate that studying the evolution of a spreadsheet helps to identify areas in the spreadsheet that are error-prone, likely to change or that could benefit from refactoring. Furthermore, by analyzing the frequency in which formulas are changed from version to version, it is possible to predict which formulas need to be changed when a new version of the spreadsheet is created.

When children learn to read, they almost invariably start with oral reading: reading the words and sentences out loud. Experiments have shown that when novices read text aloud, their comprehension is better then when reading in silence. This is attributed to the fact that reading aloud focuses the child's attention to the text. We hypothesize that reading code aloud could support program comprehension in a similar way, encouraging novice programmers to pay attention to details. To this end we explore how novices read code, and we found that novice programmers vocalize code in different ways, sometimes changing vocalization within a code snippet. We thus believe that in order to teach novices to read code aloud, an agreed upon way of reading code is needed. As such, this paper proposes studying code phonology, ultimately leading to a shared understanding about how code should be read aloud, such that this can be practiced. In addition to being valuable as an educational and diagnostic tool for novices, we believe that pair programmers could also benefit from standardized communication about code, and that it could support improved tools for visually and physically disabled programmers.

Blocks-based programming holds potential for end-user developers. Like all visual programming languages, blocks-based programming languages embody both a language design and a user interface design for the editing environment. For blocks-based languages, these designs are focused on learnability and low error rates, which makes them effective for education. For end-user developers who program as part of their professions, other characteristics of usability, like efficiency of use, will also be important. This paper presents a usability analysis, supported by a user study, of the editor design of current blocks-based programming systems, based on the Cognitive Dimensions of Notations framework, and we present design manoeuvres aimed at improving programming time and effort, program comprehension and programmer comfort.

The popularity of end-user programming has lead to diverse end-user development environments. Despite accurate and efficient tools available in such environments, end-user programmers often manually complete tasks. What are the consequences of rejecting these tools? In this paper, we answer this question by studying end-user programmers completing four tasks with and without tools. In analyzing 111 solutions to each of these tasks, we observe that neither tool use nor tool rejection was consistently more accurate or efficient. In some cases, tool users took nearly twice as long to solve problems and over-relied on tools, causing errors in 95% of solutions. Compared to manual task completion, the primary benefit of tool use was narrowing the kinds of errors that users made. We also observed that partial tool use can be worse than no tool use at all.

Spreadsheets are widely used in industry. Spreadsheets also suffer from typical software engineering issues. Previous research shows that they contain code smells, lack documentation and tests, and have a long live span during which they are transferred multiple times among users. These transfers highlight the importance of spreadsheet comprehension. Therefore, in this paper, we analyze the effect of the organization of formulas on spreadsheet comprehension. To that end, we conduct a controlled experiment with 107 spreadsheet users, divided into two groups. One group receives a model where the formulas are organized such that all related components are grouped closely together, while the other group receives a model where the components are spread far and wide across the spreadsheet. All subjects perform the same set of comprehension tasks on their spreadsheet. The results indicate that the way formulas are located relative to each other in a spreadsheet, influences the performance of the subjects in their ability to comprehend and adapt the spreadsheet. Especially for the comprehension tasks, the subjects perform better on the model where the formulas were grouped closely together. For the adaptation tasks, we found that the length of the calculation chain influences the performance of the subjects more than the location of the formulas itself.

Scratch is increasingly popular, both as an introductory programming language and as a research target in the computing education research field. In this paper, we present a dataset of 250K recent Scratch projects from 100K different authors scraped from the Scratch project repository. We processed the projects' source code and metadata to encode them into a database that facilitates querying and further analysis. We further evaluated the projects in terms of programming skills and mastery, and included the project scoring results. The dataset enables the analysis of the source code of Scratch projects, of their quality characteristics, and of the programming skills that their authors exhibit. The dataset can be used for empirical research in software engineering and computing education.

Research shows the importance of selecting good names to identifiers in software code: more meaningful names improve readability. In particular, several guidelines encourage long and descriptive variable names. A recent study analyzed the use of variable names in five programming languages, focusing on single-letter variable names, because of the apparent contradiction between their frequent use and the fact that these variables violate the aforementioned guidelines. In this paper, we analyze variables in Scratch, a popular block-based language aimed at children. We start by replicating the above single-letter study for Scratch. We augment this study by analyzing single-letter procedure names, and by investigating the use of Scratch specific naming patterns: spaces in variable names, numerics as variables and textual labels in procedure names. The results of our analysis show that Scratch programmers often prefer longer identifier names than developers in other languages, while Scratch procedure names have even longer names than Scratch variables. For the single-letter variables, the most frequent names are x, y, and i. Single-letter procedures are less popular, but show more tendency to be in upper case. When compared to the other programming languages, the usage of single uppercase letters in Scratch variables seems to be similar to the pattern found in Perl, while for the lowercase letters-to the pattern found in Java. Concerning Scratch specific features, 44% of the unique variable names and 34% of the projects in the dataset include at least one space. The usage of textual labels between parameters in procedure names appears as not common, however textual patterns used imply an influence from textual languages, for example by using brackets. Previous research indicate the identifier names as one significant issue in transitioning from visual block-based to textual programming languages. The naming patterns we found support this claim for Scratch programmers who may incur difficulties when transitioning to the use of mainstream textual programming languages. Those languages restrict the use of spaces in identifiers and more often divert into short and single-letter names- tendencies opposite to the naming preferences in Scratch.

Despite being popular end-user tools, spreadsheets suffer from the vulnerability of error-proneness. In software engineering, testing has been proposed as a way to address errors. It is important therefore to know whether spreadsheet users also test, or how do they test and to what extent, especially since most spreadsheet users do not have the training, or experience, of software engineering principles. Towards this end, we conduct a two-phase mixed methods study. First, a qualitative phase, in which we interview 12 spreadsheet users, and second, a quantitative phase, in which we conduct an online survey completed by 72 users. The outcome of the interviews, organized into four different categories, consists of an overview of test practices, perceptions of spreadsheet users about testing, a set of preventive measures for avoiding errors, and an overview of maintenance practices for ensuring correctness of spreadsheets over time. The survey adds to the findings by providing quantitative estimates indicating that ensuring correctness is an important concern, and a major fraction of users do test their spreadsheets. However, their techniques are largely manual and lack formalism. Tools and automated supports are rarely used.

Abstract Spreadsheets are popular end user programming tools, especially in the industrial world. This makes them interesting research targets. However, there does not exist a reliable grammar that is concise enough to facilitate formula parsing and analysis and to support research on spreadsheet codebases. This paper presents a grammar for spreadsheet formulas that can successfully parse 99.99% of more than 8 million unique formulas extracted from 4 spreadsheet datasets. Our grammar is compatible with the spreadsheet formula language, recognizes the spreadsheet formula elements that are required for supporting spreadsheets research, and produces parse trees aimed at further manipulation and analysis. Additionally, we use the grammar to analyze the characteristics of the formulas of the 4 datasets in 3 different dimensions: complexity, functionality, and data utilization. Our results show that (1) most Excel formulas are simple, however formulas with more than 50 functions or operations exist, (2) almost all formulas use data from other cells, which is often not local, and (3) a surprising number of referring mechanisms are used by less than 1% of the formulas.

Block-based programming languages like Scratch, Alice and Blockly are becoming increasingly common as introductory languages in programming education. There is substantial research showing that these visual programming environments are suitable for teaching programming concepts. But, what do people do when they use Scratch? In this paper we explore the characteristics of Scratch programs. To this end we have scraped the Scratch public repository and retrieved 250,000 projects. We present an analysis of these projects in three different dimensions. Initially, we look at the types of blocks used and the size of the projects. We then investigate complexity, used abstractions and programming concepts. Finally we detect code smells such as large scripts, dead code and duplicated code blocks. Our results show that 1) most Scratch programs are small, however Scratch programs consisting of over 100 sprites exist, 2) programming abstraction concepts like procedures are not commonly used and 3) Scratch programs do suffer from code smells including large scripts and unmatched broadcast signals.

Recently, block-based programming languages like Alice, Scratch and Blockly have become popular tools for programming education. There is substantial research showing that block-based languages are suitable for early programming education. But can block-based programs be smelly too? And does that matter to learners? In this paper we explore the code smells metaphor in the context of block-based programming language Scratch. We conduct a controlled experiment with 61 novice Scratch programmers, in which we divided the novices into three groups. One third receive a non-smelly program, while the other groups receive a program suffering from the Duplication or the Long Method smell respectively. All subjects then perform the same comprehension tasks on their program, after which we measure their time and correctness. The results of the experiment show that code smell indeed influence performance: subjects working on the program exhibiting code smells perform significantly worse, but the smells did not affect the time subjects needed. Investigating different types of tasks in more detail, we find that Long Method mainly decreases system understanding, while Duplication decreases the ease with which subjects modify Scratch programs.

Code smells were originally designed for object-oriented code, but in recent years, have been applied to end-user languages, including spreadsheets and Yahoo! Pipes. In this paper, we explore code smells in block-based end-user programming languages aimed at education. Specifically, we explore the occurrence of smells in two educational languages not previously targeted by smell detection and refactoring research: LEGO MINDSTORMS EV3 and Microsoft's Kodu. The results of this exploration show that object-oriented-inspired smells indeed occur in educational end-user languages and are present in 88% and 93% of the EV3 and Kodu programs, respectively. Most commonly we find that programs are plagued with lazy class, duplication, and dead code smells, with duplication smells being present in nearly two-thirds of programs in both languages.

Spreadsheets are arguably the most used form of programming, yet they are error prone and hard to maintain. This paper demonstrates novel features that enable the gradual structuring of spreadsheets to more structured models, with the intent of mitigating these issues. The approach of features for gradual structuring does not impact the underlying application. Structured models improve comprehension, reduce design and composition errors, whilst the gradual nature proposed, allows the modeller to choose what best fits their requirements. The origin of these features are the design patterns of expert spreadsheet modellers. Whilst these features increase the expressiveness of the spreadsheet paradigm future studies are planned to assess.

Spreadsheets are popular end-user computing applications and one reason behind their popularity is that they offer a large degree of freedom to their users regarding the way they can structure their data. However, this flexibility also makes spreadsheets difficult to understand. Textual documentation can address this issue, yet for supporting automatic generation of textual documentation, an important pre-requisite is to extract metadata inside spreadsheets. It is a challenge though, to distinguish between data and metadata due to the lack of universally accepted structural patterns in spreadsheets. Two existing approaches for automatic extraction of spreadsheet metadata were not evaluated on large datasets consisting of user inputs. Hence in this paper, we describe the collection of a large number of user responses regarding identification of spreadsheet metadata from participants of a MOOC. We describe the use of this large dataset to understand how users identify metadata in spreadsheets, and to evaluate two existing approaches of automatic metadata extraction from spreadsheets. The results provide us with directions to follow in order to improve metadata extraction approaches, obtained from insights about user perception of metadata. We also understand what type of spreadsheet patterns the existing approaches perform well and on what type poorly, and thus which problem areas to focus on in order to improve.

Spreadsheets are used extensively for calculations in several domains, especially in finance and insurance. Spreadsheets offer a clear benefit to their users: they are an easy to learn application in which to express their business needs, however, there are downsides too. Like software, spreadsheets can have a long life span in which they are used by several people. This leads to maintainability issues, including errors, but also often to issues with performance. In this paper we present a case study in which a model for shortfall calculations, originally implemented in a spreadsheet, was adapted to run on an HPC cluster. We present the design, analysis and implementation of the solution which clearly improved the performance of the spreadsheet, with a factor of 50 in some cases. We subsequently reflect on challenges related to reverse engineering, testing and scalability. Finally, we identify opportunities that would provide automatic support to refactoring, dependency recognition and performance profiling in future spreadsheet optimization projects.

Spreadsheets are used extensively in business processes around the world and as such, are a topic of research interest. Over the past few years, many spreadsheet studies have been performed on the EUSES spreadsheet corpus. While this corpus has served the spreadsheet community well, the spreadsheets it contains are mainly gathered with search engines and might therefore not represent spreadsheets used in companies. This paper presents an analysis of a new dataset, extracted from the Enron email archive, containing over 15,000 spreadsheets used within the Enron Corporation. In addition to the spreadsheets, we also present an analysis of the associated emails, where we look into spreadsheet-specific email behavior. Our analysis shows that 1) 24% of Enron spreadsheets with at least one formula contain an Excel error, 2) there is little diversity in the functions used in spreadsheets: 76% of spreadsheets in the presented corpus use the same 15 functions and, 3) the spreadsheets are substantially more smelly than the EUSES corpus, especially in terms of long calculation chains. Regarding the emails, we observe that spreadsheets 1) are a frequent topic of email conversation with 10% of emails either referring to or sending spreadsheets and 2) the emails are frequently discussing errors in and updates to spreadsheets.

Spreadsheets are heavily used in industry, becausethey are easily written and adjusted, using an intuitive visual interface. They often start out as simple tools; however, over time spreadsheets can become increasingly complex, up to the point where they become complicated and inflexible. In many ways, spreadsheet are similar to software: both concern the storage and manipulation of data and the presentation of results to the user. Because of this similarity, many methods and techniques from software engineering can be applied to spreadsheets. The role of SEMS, the International Workshop on Software Engineering Methods in Spreadsheets is to explore the possibilities of applying successful methods from software engineering to spreadsheets. Some, like testing and visualization, have been tried before and can be built upon. For methods that have not yet been tried on spreadsheets, SEMS will serve as a platform for early feedback. The SEMS program included an industrial keynote, "spreadsheet stories" (success or failure), short and long research papers,a good mix of industrial and academic researchers, as well as lively discussion and debate.

In previous work, code smells have been adapted to be applicable on spreadsheet formulas. The smell detection algorithm used in this earlier study was validated on a small dataset of industrial spreadsheets by interviewing the users of these spreadsheets and asking them about their opinion about the found smells. In this paper a more in depth validation of the algorithm is done by analyzing a set of spreadsheets of which users indicated whether or not they are smelly. This new dataset gives us the unique possibility to get more insight in how we can distinguish `bad' spreadsheets from `good' spreadsheets. We do that in two ways: For both the smelly and non smelly spreadsheets we 1) have calculated the metrics that detect the smells and 2) have calculated metrics with respect to size, level of coupling, and the use of functions. The results show that indeed the metrics for the smells decrease in spreadsheets that are not smelly. With respect to size we found to our surprise that the improved spreadsheets were not smaller, but bigger. With regard to coupling and the use of functions both datasets are similar. It indicates that it is difficult to use metrics with respect to size, degree of coupling or use of functions to draw conclusions on the complexity of a spreadsheet.

Spreadsheets are ubiquitous in the industrial world and often perform a role similar to other computer programs, which makes them interesting research targets. However, there does not exist a reliable grammar that is concise enough to facilitate formula parsing and analysis and to support research on spreadsheet codebases. This paper presents a grammar for spreadsheet formulas that is compatible with the spreadsheet formula language, is compact enough to feasibly implement with a parser generator, and produces parse trees aimed at further manipulation and analysis. We evaluate the grammar against more than one million unique formulas extracted from the well known EUSES and Enron spreadsheet datasets, successfully parsing 99.99%. Additionally, we utilize the grammar to analyze these datasets and measure the frequency of usage of language features in spreadsheet formulas. Finally, we identify smelly constructs and uncommon cases in the syntax of formulas.

Spreadsheets are used heavily in many business domains around the world. They are easy to use and as such enable end-user programmers to and build and maintain all sorts of reports and analyses. In addition to using spreadsheets for modeling and calculation, spreadsheets are often also used for creating reports and dashboards: combining data from different sources and creating overviews. For this, lookup functions can be used: they search for a value in a range and return a corresponding row or column. Lookup functions are common: according to recent research the VLOOKUP is the fifth most common Excel function. In this paper we investigate the use of lookup functions in more detail. We analyze lookup functions within the newly released Enron spreadsheet corpus. The results show that 1) a minority of 43% of lookup formulas use the default setting where an approximate match may be returned, 2) 77% of approximate matches are used unnecessary and 3) 23% of approximate lookups is problematic: they search over unsorted ranges, while this is specifically advised against in the specification, and might lead to wrong results.

Spreadsheets are widely used in industry. It is estimated that end-user programmers outnumber regular programmers by a factor of 5. However, spreadsheets are error-prone: several reports exist of companies that have lost big sums of money due to spreadsheet errors. In previous work, spreadsheet smells have proven to be the cause of some of these errors. To that end, we have developed a tool that can apply refactorings to spreadsheet formulas, implementing our previous work on spreadsheet refactoring, which showed that spreadsheet formula smells are very common and that refactorings for them are widely applicable and that refactoring them with a tool is both quicker and less error-prone. Our new tool Bumblebee is able to execute refactorings originating from both these papers, by means of an extensible syntax, and can furthermore apply refactorings on entire groups of formulas, thus improving upon the existing tool RefBook. Finally, BumbleBee can also execute transformations other than refactorings.

Spreadsheets are widely used in industry: it is estimated that end-user programmers outnumber programmers by a factor 5. However, spreadsheets are error-prone, numerous companies have lost money because of spreadsheet errors. One of the causes for spreadsheet problems is the prevalence of copy-pasting. In this paper, we study this cloning in spreadsheets. Based on existing text-based clone detection algorithms, we have developed an algorithm to detect data clones in spreadsheets: formulas whose values are copied as plain text in a different location. To evaluate the usefulness of the proposed approach, we conducted two evaluations. A quantitative evaluation in which we analyzed the EUSES corpus and a qualitative evaluation consisting of two case studies. The results of the evaluation clearly indicate that 1) data clones are common, 2) data clones pose threats to spreadsheet quality and 3) our approach supports users in finding and resolving data clones.

Spreadsheets are often used in business, for simple tasks, as well as for mission critical tasks such as finance or forecasting. Similar to software, some spreadsheets are of better quality than others, for instance with respect to usability, maintainability or reliability. In contrast with software however, spreadsheets are rarely checked, tested or certified. In this paper, we aim at developing an approach for detecting smells that indicate weak points in a spreadsheet's design. To that end we first study code smells and transform these code smells to their spreadsheet counterparts. We then present an approach to detect the smells, and to communicate located smells to spreadsheet users with data flow diagrams. To evaluate our apporach, we analyzed occurrences of these smells in the Euses corpus. Furthermore we conducted ten case studies in an industrial setting. The results of the evaluation indicate that smells can indeed reveal weaknesses in a spreadsheet's design, and that data flow diagrams are an appropriate way to show those weaknesses.

Spreadsheets are used extensively in business processes around the world and just like software, spreadsheets are changed throughout their lifetime causing maintainability issues. This paper adapts known code smells to spreadsheet formulas. To that end we present a list of metrics by which we can detect smelly formulas and a visualization technique to highlight these formulas in spreadsheets. We implemented the metrics and visualization technique in a prototype tool to evaluate our approach in two ways. Firstly, we analyze the EUSES spreadsheet corpus, to study the occurrence of the formula smells. Secondly, we analyze ten real life spreadsheets, and interview the spreadsheet owners about the identified smells. The results of these evaluations indicate that formula smells are common and that they can reveal real errors and weaknesses in spreadsheet formulas.

Thanks to their flexibility and intuitive programming model, spreadsheets are widely used in industry, often for businesscritical applications. Similar to software developers, professional spreadsheet users demand support for maintaining and transferring their spreadsheets.