Notes from WEUSE IV Discussions

1. Notes from WEUSE IV Discussions

2. Notes Carolyn Seaman, UMBC. Bioinformatics, big spectrum, part of it is EUP. Interested in EUSE. Malea Umarji, UMBC, with Carolyn Seaman, “Bioinformatics SE”. Survey to inform, need to educate students in this are on suitable SE principles. Kevin McDaid, ** Inst. Tech., Ireland, use spreadsheets “to death”, spreadsheets are huge bowls of spaghetti. 1. Test-driven development for spreadsheets. Encourages decomposition (bottom up). People find easy to learn, but they aren’t sure it’s worth the time. Need studies to explain more about why/when it works. 2. Which cells do people look at in testing spreadsheets. Experts more rigorous at code inspection. Novices are the ones who follow spatial. Some experts can go thru cells in about .4 sec/cell (very fast!). Some evidence that tool supporting “todo listing” might work. 3. Interested in spreadsheet repository. Interested in how to argue for respectability of EUSE to funders. Interested in collaboration. (cont. next slide)

3. Notes (cont.) Maria Francesca Costabile, Univ. Bari, Italy, unwitting programmers, others’ research points that children actually do sophisticated programming, but they don’t know it’s programming. Interactive simulations, animations, games, … Emphasis on construction though. This phenomenon is what Costabile et al. have observed in a number of domains (medical, mech. engrs., geologists). There is a consortium of these companies, with whom Costabile et al. collaborate to help with these domains’ needs. Domain experts (eg, physicians) do not even think they are programming. Prefers the term “end-user development” to EUP to reflect the unwittingness. (cont. next slide)

4. Notes (cont.) Piero Mussio, Univ. Milan, Italy. Collaborator of Costabile. System for archeologists, and for mech. Engrs. Domain-specific languages. Archeologists construct knowledge base (of documents) which they then need to navigate. Mech engrs, on the other hand, do things much more traditionally. Languages must reflect THEIR (the EUPs’) views of the activities. Establishing SE for these people invent strategies that are non-trditional. They too observed . Joel Brandt, Stanford. Sees work as being on fringes of EUSE. Especially interested in supporting designers. Encouraging “design thinking”, learning by doing. Tied to “prototyping at the 15-minute level.” 1. Deeper understanding of copy/paste in programming. Intent of the experience seems to differ greatly: eg to save retyping, replace learning. 2. Shortening iteration time. Want to give feedback on this. 3. Support versioning at a more fine-grained level.

5. Discussion Carolyn Seaman adds a question. Has there been work on diversity? Motivation? What kinds of background? Occupations? Andy Ko: Doing a little bit about that in a survey we’re writing on EUSE. Stay tuned! (To appear.) Different motives, eg external goal, which leads to different tasks in differences their SE activities. Yvonne Dittrich, Univ. Copenhagen: context matters. Back-office applications folks were very aware of need for testing. Also matters: if close cooperation with prof SEs. Etc. Peter Sestoft, Univ. Copenhagen: very interested in the bioinformatics work. Build very complex systems. In old physicists checked each others’ expts, but now just share software (unchecked?). The challenge has been there a long time. Chris Scaffidi, Carnegie Mellon: Did 2 studies to characterize EUPs. VLHCC 2005. Splits out populations. Also did a survey of Information Week readers (mostly IT managers). Could characterize their feature usage by (1) whehter created linked structures, (2) whether did imperative programming, and (3) whether did macros. VLHCC 2006. Features a person used seemed to transfer across the tools. Other people have also been gathering data (see refs in his papers). (Cont. next slide).

6. DIscussion (cont.) Volkmar Pipek, Univ. Siegen, Germany: Points to paper by Gerhard Fischer relevant to different types of EUPs/EUSE. Need to articulate problems, even when they don’t directly work on the code. Andy Ko, Carnegie Mellon: More on dimensions (from WEUSE III, Dagstuhl). One was domains, familiarity with their domain, how far had they planned the software they’re developing (months? Hours? Not at all?), differences in interest in the code itself, complexity of the domain. Jeff Wong, Carnegie Mellon: Tools for EUPs to create mashups. Right fit: people using data from multiple websites, something repetitive. How could they realize they would benefit from a mashup. (cont. next slide)

7. DIscussion (cont.) Mary Shaw, Carnegie Mellon: Following up on Chris Scaffidi’s comments: Withing 4 years, 90 million people in the US alone will be using computers in the workspace to solve problems. Within that vast number, we need to identify subpopulations. Andy and Chris have characterized them various ways. One thing that we should really think about is the level of expertise people bring to the table. Unwitting/witting is one thing that approaches that, but we maybe should think more explicitly about specific expertises and consequent levels of engagements that come with it. Similar to the Bloom Taxonomy used in education. If we could get something like that, (eg, I can copy/paste values vs I can drop into Visual Basic and write macros vs. I can code in FORTRAN vs …) Would lead to more specific knowledge about power vs. generality tradeoffs. (Cont. next slide)

8. Discussion (cont.) Maria Francesca Costabile: Agrees with Mary. Need this kind of classification. Subclasses. How about a task force of people with expertise about different types of end users. Could point out the populations in the space that have been studied, what we know about those points, and where the completely unstudied spaces are. Piero Mussio: discussion too much focused on our community. Physicists check each others’ software, take software more serious. Some do try to understand more about how to develop software, software as an important asset, some don’t.