Helping End-User Programmers Share Their Creations (literature review)

1. Helping End-User ProgrammersShare Their Creations(literature review) Christopher Scaffidi Carnegie Mellon University ISR Software Research Seminar 4/16/07

2. Kids “share” creations on the fridge. Of course, other kids better not mess with posted pictures! This is “read-only” “sharing”... different from “sharing code”! Introduction

3. End-user programmers (EUPs) have plenty of programs to share. Much more complex than pictures on the fridge! • EUPs’ programs include: • Spreadsheets • Web forms • Databases • Macros • Scripts • With pictures on the fridge, WYSIWYG. • With programs, WYG is more than WYS due to dynamic behavior of code. Introduction

4. Unfortunately, current sharing approaches for EUPs have serious limitations. • “Point-to-point” • Go to the guru (in person, or via email) [Nar93, Seg04, Wie05] • Problem: Not scalable; # links ~ O(#gurus * #EUPs) • Result: Without the presence of a guru, programs are dead • “Multicast” • Go to internet (web, newsgroups, special sites) [Ros04, Ros05] • Problem: Lots of irrelevant, hard-to-adapt material • Result: Real reuse is limited to ideas & data (e.g.: images) • Professionals’ traditional approach is a “repository“ • Organizational or global (e.g.: SourceForge) Introduction

5. EUPs’ “real work” is not programming. • Professional programmers (PPs): program = deliverable • End-user programmers (EUPs): program = means to end • PPs often have incentives to plan for reusability. • EUPs often do not. [Ros04, Seg04, Wie05] • Thus, EUPs allocate very little time… • For designing reusable “components” • For creating documentation • For getting training in software design • I will discuss implications for repository use by EUPs… Introduction

6. This talk develops a to-do list. • Adapting the repository approach for EUPs will require: • Post-hoc abstraction mechanisms • A way to easily document abstractions • A way to cloak private data in programs • Integration of trustworthiness into repositories • Objective: • To review a body of interesting problems & approaches that I discovered while reading the literature about EUPs. • This will not be a thesis to-do list. • But the material does have implications for my research. Outline

7. Code is much easier to reuse if it is “wrapped” in an abstraction. • Would you prefer a pile of code, or a crisp API? • PPs can share libraries • Write, compile, jar/zip up class libraries • Other PPs instantiate objects, call parameterized methods • Tools often only let EUPs share whole programs • How to “call” a reusable spreadsheet, web form, or macro? • Also, EUPs lack incentives to design for reuse [Seg04, Wie05] Abstractions

8. Many research tools enable EUPs to create functional and data abstractions. Abstractions

9. To-do list, item #1 • Needed: a mechanism so EUPs can conveniently create abstractions that are smaller than whole programs • Possible approach: support abstraction after-the-fact by adapting refactoring algorithms [Gal99, Gri98] • E.g.: highlight a segment of code text, and tell the algorithm to make this code a function; it automatically determines the right parameters & writes a function • Other algorithms can extract classes, create packages, extract parameters, etc. • Extracted abstractions should be reusable across tools • A la Microsoft.NET… • E.g.: Shouldn’t a JavaScript function be callable from spreadsheet cells, spreadsheet macros, and databases? Abstractions

10. Code is much easier to understand and reuse if it is documented. • Documentation uses “secondary notation” [Gre06] • PPs can generate docs from JavaDoc. • Embedded within the code. • Or stored on the web & referenced with a link in the code • (Even better, they will soon have Design Fragments!) • Some EUP tools lack good places to put documentation • E.g.: macros, spreadsheets, databases • Another obstacle to documentation by EUPs: • EUPs lack incentives to write documentation [Seg04, Wie05] Documentation

11. To-do list, item #2 • Needed: post-hoc abstraction mechanisms • Needed: a way to easily document EUPs’ abstractions • Approach #1: Make code more human-readable (e.g.: Koala web macros look very like English) [Lit07] • Ideally, this will make programsmore self-documenting • (A very old approach) Documentation

12. To-do list, item #2 • Needed: post-hoc abstraction mechanisms • Needed: a way to easily document EUPs’ abstractions • Approach #1: Make code more human-readable • Approach #2: Auto-generate code from English [Lie06] • Very domain-specific • (an old dream) Documentation

13. To-do list, item #2 02/ 31-99 is a valid instance of this pattern • Needed: post-hoc abstraction mechanisms • Needed: a way to easily document EUPs’ abstractions • Approach #1: Make code more human-readable • Approach #2: Auto-generate code from English • Approach #3: Embed examples of data abstractions • E.g.: Embed examples to explain Lapis patterns [Mil02a] @DayOfMonth is Number equal to /[12][0-9]|3[01]|0?[1-9]/ ignoring nothing @ShortMonth is Number equal to /1[012]|0?[1-9]/ ignoring nothing @ShortYear is Number equal to /\d\d/ ignoring nothing Date is flatten @ShortMonth then @DayOfMonth then @ShortYear ignoring either Spaces or Punctuation Documentation

14. To-do list, item #2 • Needed: post-hoc abstraction mechanisms • Needed: a way to easily document EUPs’ abstractions • Approach #1: Make code more human-readable • Approach #2: Auto-generate code from English • Approach #3: Embed examples of data abstractions • Approach #4: Make it easy to locate examples online • Take a page from Mica, a search tool for Java code [Sty06] • Given a phrase (e.g.: “open secure socket”), Mica issues Google queries to locate code that demonstrates how to use Java APIs to open an SSL socket • To consider: if I created a reusable spreadsheet abstraction, what would a good “how to use this” example look like? Documentation

15. EUPs’ programs often have embedded, unsharable data. • In the PP case (e.g.: Java), the program source code does not contain data. • Not so with many EUPs’ programs • E.g.: spreadsheets, web forms, databases • It might be bad to share data with other EUPs. • Removing data would make spreadsheets less understandable! • Removing data is somewhat in conflict with using examples as a form of documentation. Data cloaking

16. To-do list, item #3 • Needed: post-hoc abstraction mechanisms • Needed: a way to easily document abstractions • Needed: a way to “cloak” private data in EUPs’ programs • Possible approach: privacy-preserving anonymization • Private data can be intentionally “damaged” in a way that makes it less traceable back to an individual yet does not render the data worthless for other purposes. [Swe03] • A method would be needed to help EUPs find data in their programs that should probably be anonymized (e.g.: social security & credit card numbers). • Very hard cases exist, too (e.g.: Has AIDS? “Y” / “N”) • What do HIPAA, SOX, and other regulations have to say? Data cloaking

17. Code is more likely to be reused if it is “trustworthy.” Can you please be more specific? Trust

18. PPs have many techniques for evaluating trustworthiness of code. • “High-ceremony” sources of evidence include: [Sca07][Sha03] • Formal verification • Code generation by a trusted automatic generator • Systematic testing • Careful empirical studies • High-ceremony sources of evidence require: [Sca07] • Require fairly precise specifications • Require substantial investment of effort • May be unavailable • May be hard for EUPs to interpret • ([Boo02] characterizes “high-ceremony software processes”) Trust

19. In real life™, we trust people and things based on “low-ceremony” evidence. Trust

20. Code repositories have yet to tap most low-ceremony sources of evidence. Trust

21. To-do list, item #4 • Needed: post-hoc abstraction mechanisms • Needed: a way to easily document abstractions • Needed: a way to cloak private data in programs • Needed: integration of trustworthiness into repositories • Promising approach: trust-based filtering in search tools • Reputation and references have been used for finding… • Matlab code [Gul06] • Spreadsheets [Bur02] • Web services [Zen04] • General software components [Bel99] Trust

22. This talk developed a to-do list. • If you want to help EUPs share programs, then develop: • Post-hoc abstraction mechanisms • A way to easily document abstractions • A way to cloak private data in programs • Integration of trustworthiness into repositories • For each item, there are promising approaches. • These approaches will need to be adapted to help EUPs. Summary

23. References (1) [Bal02] M. Balaban, E. Barzilay, and M. Elhadad. Abstraction as a Means for End User Computing in Creative Applications. IEEE Transactions on Systems, Man and Cybernetics, Part A, 32, 6 (Nov. 2002), pp. 640-653. [Bel99] C. Bellettini, E. Damiani, and M. Fugini. User Opinions and Rewards in Reuse-Based Development System. Proceedings of the 1999 Symposium on Software Reusability, 1999, pp. 151-158. [Bla01] A. Blackwell and R. Hague. AutoHAN: An Architecture for Programming the Home. In Proceedings of the IEEE 2001 Symposia on Human Centric Computing Languages and Environments, 2001, pp. 150-157. [Boo02] G. Booch. Developing the Future. Communications of the ACM, Vol. 44, No. 3, 2001, pp. 118-121. [Bur02] M. Burnett. Software Engineering for Visual Programming Languages, Handbook of Software Engineering and Knowledge Engineering, World Scientific Publishing Company, Vol. 2, 2002, pp. 77-92. [Dou90] S. Douglas, E. Doerry, and D. Novick. D. Quick: A User-Interface Design Kit for Non-Programmers. In Proceedings of the 3rd Annual ACM SIGGRAPH Symposium on User Interface Software and Technology, 1990, pp. 47-56. [Fis90] G. Fischer and A. Girgensohn. End User Modifiability in Design Environments. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 1990, pp. 183-192. [Gal99] K. Gallagher and J. Lyle. Using Program Slicing in Software Maintenance. IEEE Transactions on Software Engineering, Vol. 17, No. 8, 1991, pp. 751-761. References

24. References (2) [Gra00] T. Grandison and M. Sloman. A Survey of Trust in Internet Applications. IEEE Communications Surveys and Tutorials, Vol. 3, No. 4, 2000, pp. 2-16. [Gre06] T. Green, et al. Cognitive Dimensions: Achievements, New Directions, and Open Questions. Journal of Visual Languages and Computation, 17.4, 2006, pp. 328-365 [Gri98] W. Griswold, et al. Tool Support for Planning the Restructuring of Data Abstractions in Large Systems. IEEE Transactions on Software Engineering, Vol. 24, No. 7, July 1998, pp. 534-558. [Gul06] N. Gulley. Improving the Quality of Contributed Software and the MATLAB File Exchange, Proceedings of the 2nd Workshop on End User Software Engineering (WEUSE II), 2006, pp. 8-9. [Has01] R. Hastie and R. Dawes. Rational Choice in an Uncertain World: The Psychology of Judgment and Decision Making, Sage Publications, 2001. [Huy04] T. Huynh, N. Jennings, and N. Shadbolt. Developing an Integrated Trust and Reputation Model for Open Multi-Agent Systems. In Proceedings of the 7th International Workshop on Trust in Agent Societies, 2004, pp. 65-74. [Jon03] S. Jones, A. Blackwell, and M. Burnett. A User-Centred Approach To Functions in Excel. ICFP '03: Proceedings of the Eighth ACM SIGPLAN International Conference on Functional Programming, 2003, pp. 165-176. [Jos07] A. Jøsang, R. Ismail, and C. Boyd. A Survey of Trust and Reputation Systems for Online Service Provision. Decision Support Systems, Vol. 43, No. 2, 2007, pp. 618-644. [Lie06] H. Lieberman, H. Liu, and Y. Li. End-User Software Engineering in Natural Language, Proceedings of the 2nd Workshop on End User Software Engineering (WEUSE II), 2006, pp. 38-40. References

25. References (3) [Lit07] G. Little, T. Lau, J. Lin, E. Kandogan, E. Haber, and A. Cypher. Koala: Capture, Share, Automate, Personalize Business Processes on the Web. CHI’07: Proceedings of the 25th Conference on Human Factors in Computing Systems, 2007, to appear. [Mar94] J. March. A Primer on Decision Making: How Decisions Happen, Free Press, 1994. [Mcd99] R. McDaniel and B. Myers. Getting More Out of Programming-By-Demonstration. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 1999, pp. 442-449. [Mil02] R. Miller and B. Myers. LAPIS: Smart Editing with Text Structure. In CHI '02 Extended Abstracts on Human Factors in Computing Systems, 2002, pp. 496-497. [Mil02a] R. Miller. Lightweight Structure in Text. PhD thesis, Computer Science Department, School of Computer Science, Carnegie Mellon University, 2002 [Mod94] F. Modugno and B. Myers. Pursuit: Graphically Representing Programs in a Demonstrational Visual Shell. In Proceedings of the CHI '94 Conference Companion on Human Factors in Computing Systems, 1994, pp. 455-456. [Nar93] B. Nardi. A Small Matter of Programming, MIT Press, 1993. [Ram04] S. Ramchurn, D. Huynh, and N. Jennings. Trust in Multi-Agent Systems. Knowledge Engineering Review, Vol. 19, No. 1, 2004, pp. 1-25. [Ros04] M. Rosson, J. Ballin, and H. Nash. Everyday Programming: Challenges and Opportunities for Informal Web Development. Visual Languages and Human Centric Computing, 2004 IEEE Symposium on, 2004, pp. 123-130. References

26. References (4) [Ros05] M. Rosson, J. Ballin, and J. Rode. Who, What, and How: A Survey of Informal and Professional Web Developers. Proceedings of the 2005 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC'05), 2005, pp. 199-206. [Sab03] J. Sabater. Trust and Reputation for Agent Societies. IIIA Monograph Series, Vol. 20, 2003. [Sca07] C. Scaffidi and M. Shaw. An Inventory of Techniques that Predict Value from Design, working paper predictor-table-v2-7, Institute for Software Research, Carnegie Mellon University, Dec 8, 2007, http://www.cs.cmu.edu/~cscaffid/papers/predictor-table-v2-7.pdf [Seg04] J. Segal. Professional End User Developers and Software Development Knowledge. Technical Report 2004/25, Department of Computing, Faculty of Mathematics and Computing, the Open University, Milton Keynes, United Kingdom, Oct 2004 [Sha03] M. Shaw. Writing Good Software Engineering Research Papers. Proceedings of the 25th International Conference on Software Engineering, 2003, pp. 726-736. [Smi94] D. Smith, A. Cypher, and J. Spohrer. KidSim: Programming Agents without a Programming Language. Communications of ACM, 37, 7 (July 1994), pp. 54-67. [Sta01] J. Stafford and K. Wallnau. Is Third Party Certification Necessary?. Proceedings of the 4th ICSE Workshop on Component–Based Software Engineering, 2001, pp. 33-40. [Sty06] J. Stylos and B. Myers. Mica: A Web-Search Tool for Finding API Components and Examples. Proceedings of the Visual Languages and Human-Centric Computing (VL/HCC'06), 2006, pp. 195-202. References

27. References (5) [Swe03] L. Sweeney. Navigating Computer Science Research Through Waves of Privacy Concerns: Discussions among Computer Scientists at Carnegie Mellon University, Technical Report CMU-ISRI-03-102, July 2003. [Tad03] S. Tadelis. Firm Reputation with Hidden Information. Economic Theory, Vol. 21, No. 2-3, Mar 2003, pp. 635-651. [Tex99] G. Texier and L. Guittet. User Defined Objects Are First Class Citizens. In Proceedings of the 3rd International Conference on Computer-Aided Design of User Interfaces, 1999, pp. 231-244. [Wie05] S. Wiedenbeck. Facilitators and Inhibitors of End-User Development by Teachers in a School Environment. IEEE Symposium on Visual Languages and Human-Centric Computing, 2005, pp. 215-222 [Zen04] L. Zeng, B. Benatallah, A. Ngu, and M. Dumas. QoS-Aware Middleware for Web Services Composition. IEEE Transactions on Software Engineering, Vol. 30, No. 5, 2004, pp. 311-327. References

28. Thank you • To Mary Shaw and Brad Myers for suggestions about helping EUPs understand and share programs. • To ISR for the opportunity to present today. • To NSF for funding. • To www.epa.gov and www.pueblo.gsa.gov for images. Thank You

29. This literature inspired several ideas for helping EUPs share topes. • Tope = a package of executable software functions for recognizing, transforming, and equivalence-testing instances of a category of data • E.g.: recognize ###-###-#### and (###) ###-####as phone numbers, transform between these formats, and test equivalence of values • Post-hoc abstraction: creating topes from examples • Documentation: document by embedding example values • Data cloaking: topes can be used to find data for cloaking • Trust: annotate topes with meta-information containing many low-ceremony sources of evidence Implications for my research