1. 1 Institute for Software Research, International BEHOLD, WE HAVE SIGNAL

2. 2 Institute for Software Research, International Software Engineering vs (???) End User Software Engineering Mary Shaw with Jim Herbsleb, Ipek Ozkaya Carnegie Mellon University http://www.cs.cmu.edu/~shaw/

3. 3 Institute for Software Research, International CMU’s approach to SE education  Distinctive nature of engineering for software v Software is design-intensive; manufacturing cost is small v Software is symbolic, abstract, more constrained by complexity than by physical laws  Software engineering rests on three foundations v Core computer science: technical conceptual foundation v Engineering knowledge: design and problem solving v Social and economic context: basis for fitness for use Software engineering is the branch of computer science that creates practical, cost-effective solutions to computation and information processing problems, preferentially applying scientific knowledge

4. 4 Institute for Software Research, International Computer science fundamentals  Abstraction enables the control of complexity  Common problem structures lead to canonical solutions  Imposing structure on problems often makes them more tractable; a number of common structures are available  Symbolic representations are necessary and sufficient for solving information-based problems  Precise models support analysis and prediction

5. 5 Institute for Software Research, International Engineering fundamentals  Engineering quality resides in engineering judgment.  Engineering skills improve as a result of careful systematic reflection on experience  Quality of the software product depends on the engineer's faithfulness to the engineered artifact  Engineering requires reconciling conflicting constraints

6. 6 Institute for Software Research, International Social and economic fundamentals  Costs and time constraints matter, not just capability  Customers and users usually don’t know precisely what they want, and the developer must facilitate the discovery of the requirements  Technology improves exponentially, but human capability does not  Successful software development depends on teamwork by creative people  Business and policy objectives constrain software design as much as technical considerations do  Software functionality is often so deeply embedded in institutional arrangements that observational methods are required

7. 7 Institute for Software Research, International So, what’s special about end users?  Professionals about something other than software v Software is job #2 (or maybe #6) v Less likely than prof programmers to take long view  Often develop software within applications, not in programming environments v Aren’t aware of engineering issues (testing, evolution, …) v Don’t get much support from applications or peers v Often do shallow programming – mimicry, not design  They are not all alike v Different degrees of formal skill v Different needs for variation on basic software themes v Software fits organization in different ways

8. 8 Institute for Software Research, International Categorizing End User Programmers  2012: 90 million people will user computers at work v 55M spreadsheet/database, 13M “programmer”  What are they all doing? How do they think about SW? v Listing apps doesn’t help us understand how to help them v So find a better way to characterize them  What is “programming-like” behavior? Who does it? v We have estimates of application usage v But they confound subpopulations v But they don’t distinguish sophistication of use v But they don’t identify commonality across applications Chris Scaffidi, Mary Shaw, Brad Myers

9. 9 Institute for Software Research, International Categorizing End User Programmers  So study what abstractions use, and how v End user tools provide some, not much, abstraction v Preliminary survey in Information Week F Asks about applications used – and features v Do followup survey on specific population (marketing) F Next fall  Expect to find v Use of abstractions such as function definition, data representation, scripting, data flow/propagation … v Different levels of abstraction in use (e.g, Bloom’s)

10. 10 Institute for Software Research, International Two Principles of End User SE Research  Not all end user developers are the same  Here: professional end user developers, e.g, scientists v Use formalisms professionally  coding per se not a problem v Field studies: interviews of financial consultants & scientists  Professional end user developers (vs programmers) v Goal is not code, but correct code matters v Low status for programmer  neglect for testing, maint, etc  Research must be grounded in field studies of actual end user development practice Judith Segal

11. 11 Institute for Software Research, International Two Principles of End User SE Research  Ideas from field studies for helping prof end users v Don’t consider support that disrupts user context v Consider software reuse & knowledge management tools  Obvious support mechanisms not effective v In-house software manual created but unmaintainable v Improvements require resources and new attitudes  Consider popular ideas v Standard development methods heavy; consider agile v Component technology, but requirements must evolve v Tailorable evolution may work if “product line” fits

12. 12 Institute for Software Research, International Old Issues, New Eyes  End users create software without help from IT v They can create immediate functionality v But they don’t make provisions for sustaining the software  Inherent conflicts (well known) v Domain knowledge vs technical knowledge v Central control vs local autonomy (efficiency vs availability)  Evolution v More computing power in hands of more sophisticated users v Development is easier via spreadsheets (e.g.) and COTS Michael M Pickard

13. 13 Institute for Software Research, International Old Issues, New Eyes  New issues v Offshore development reduces # of local technical experts, creating more incentives for end user development v Falling enrollments reduces availability of tech personnel v IT curricula much more applied than CS curricula  Questions v Will greater abstraction cause convergence of end user and professional developers? v With fewer tech developers, who will create and maintain the applications that support end user abstractions? v Where will COTS come from?

14. 14 Institute for Software Research, International Six Challenges in Supporting User Debugging  Study of interactive fault localization in spreadsheets yields challenges in end debugging  55M+ end users create software in many apps v Many nontrivial faults v Need implicit support for end user software engineering  Context: WYSIWYT testing with coverage display tool v Lack of progressive coverage localizes faults v Like programmers, end users need testing support F But professional and end user developers are different Joseph R Ruthruff and Margaret Burnett

15. 15 Institute for Software Research, International Six Challenges in Supporting User Debugging  Challenges for debugging and other end-user activity v Lack of software engineering knowledge F So provide tools that don’t require deep SE knowledge v Need for interactive incremental tools, not modal tools F So match interaction style of tools to that of users v Lack of organized (e.g. testing) infrastructure F So see what we can do without large prior knowledge bases v End users don’t accurately evaluate program output F So make tools resilient to user errors v Interactive techniques harder to evaluate (no batches) F So support users’ natural interaction style in debugging, too v First use of new technique is risky F So provide short-term rewards

16. 16 Institute for Software Research, International Theme: End users are not programmers  Scaffidi: Look at programming-like activities that may not involve a programming language  Segal: Programming is job 2: won’t change processes to take advantages of development method  Pickard: Users take a local view, don’t understand or appreciate long-term or policy issues (e.g., security), but can create sophisticated applications  Ruthruff: Incremental, interactive, risk-averse, unfamiliar with benefits of SE tools

17. 17 Institute for Software Research, International Theme: Innocence of Long Term  Scaffidi: Much end user activity is in applications that do not include support for sustainability  Segal: End users don’t have patience to adopt discipline that pays off only in the long run  Pickard: End users don’t see need for documentation, change control, security, audit, standards, etc  Ruthruff: End users are risk averse, do not appreciate need for SE techniques

18. 18 Institute for Software Research, International Theme: Many types of users  Scaffidi: wants to identify types of abstractions and see which people use them, at what sophistication  Segal: studied professional end user developers, e.g., scientists  Pickard: studied software developers in banks  Ruthruff: chose spreadsheet users

19. 19 Institute for Software Research, International Discussion questions  What are the differences in activities between end user programmers and professional programmers?  What are the differences in modes of thought between end user programmers and professional programmers?  What are appropriate support tools (version control, maintenance, documentation, backup, etc) for the applications used by end user programmers?  How can engineering support tools and techniques provide immediate rewards that will encourage use?  How can we make support and administrative functions (e.g., security, change mgt) scrutable

20. 20 Institute for Software Research, International Reflection Many of the same concerns arise in software engineering, but with different tools This is not so much about Software Engineering vs End User Software Engineering as about Software Engineering vs Programming (for End Users)