From EUP to EUSE:What We’ve Learned

From EUP to EUSE:What We’ve Learned

Margaret BurnettOregon State University

- 2 -

End-User Software Engineering: Beyond EUP

• Today, end users can create programs.

– e.g., macros by demo, spreadsheets, email filtering rules,web authoring tools, graphical languages...

• But what happens next?

– Usually, bugs <many citations here>.

– Compounded by overconfidence.

• How to help solve this: learning from the end users.

- 3 -

End-User Software Engineering (cont)

• What is EUSE?

– Takes into account all of the software lifecycle.

• Not just “create new programs”.

– Requirements, design, programming, debugging, testing, maintenace, reuse, …

- 4 -

Interest in EUSE

• Recent events

– International media interest:NSF press release, ACM TechNews, CNN.com, CBS.com, PC Magazine, IEEE Software editorial…

– CHI’04/05/07/08 SIGs, ICSE’05 workshop, CHI’06 workshop, many papers at recent CHIs, ICSEs, and VL/HCCs, ...

• Here at ICSE’08

– This workshop, EUSE keynote!

What We’ve Learned about EUSE from End UsersWhat We’ve Learned about EUSE from End Users

- 6 -

Organization of this Topic

• Spreadsheet debugging

– and testing and code inspection

– In light of gender differences

• Unwitting end-user programmers

• “Witting” end-user programmers

• How tools can be more natural for end-user programmers

- 7 -

Spreadsheet Debugging

• Bishop/McDaid, Burnett et al., McDaid et al.

• Via code inspection

– Code inspection matters in debugging and spreadsheet debugging

• to both males & females, but especially to females

- 8 -

Eight End-User Spreadsheet Debugging Strategies

8

• Dataflow

• Testing

• Code Inspection

• Specification Checking

• Color Following

• To-do Listing

• Fixing Formulas

• Spatial

- 9 -

Code Inspection

– Recommended by spreadsheet auditors.

– Why females particularly like it: possibly information processing:

• Comprehensive vs. heuristic processing.

– In our studies, end-user programmers usually start with code insp, then move on to testing and other approaches if needed.

- 10 -

Code Inspection by EUPs

– Business professionals outperformed business students at debugging.

– Inspecting more cells led to more errors corrected.

– Inspections focused more on top and left in groups, in bottom-line cells, and in formulas producing numeric outputs.

- 11 -

What Else We Know about Male & Female Spreadsheet EUPs

– For females: self-efficacy matters in spreadsheet auditing feature usage.

• Not so for males.

– Males tinker with new features more.

• For males, this is sometimes good, sometimes not.

• For females, tinkering is always good, but they don’t do it enough.

0

5

10

15

20

25

30

35

0

5

10

15

20

25

30

35

- 12 -

What Else We Know about Spreadsheet EUPs (cont.)

– WYSIWYT Testing (Burnett/Rothermel) is achievable and useful for EUPs, especially males.

– McDaid et al. also showing some success with spreadsheet testing.

- 13 -

Unwitting vs. Witting Software Development

– Costabile et al., Borggrafe et al., Brandt et al.

– A spectrum of end-user involvement in software.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

- 14 -

Unwitting Software Developers (cont.)

– Eg, “meta-design” (Fisher et al., Costabile et al., Borggrafe et al.)

• Designing/modeling, and/or working hand-in-hand with professional developers.

– Eg, “Tailoring”: Some do not realize that they are doing software development.

• Costabile et al. report this with medical domain experts

• Petre/Blackwell report this with children game players.

– Task-motivated (not programming-motivated), goal-directed, learning incrementally as they go.

- 15 -

“Witting” EUPs

• Segal’s study:

– Scientists who explicitly program, but don’t view their software as an outcome or an asset.

– Software not valued, not tested, not documented, not shared.

• Clarke and Brandt et al. call EUP developers (and others) like this “opportunistic”.

- 16 -

Opportunistic Programming

• 5 characteristics (Brandt et al.)

– 1. Easier to build from scratch than to understand code libraries.

• Happy to use tools new to them, if map well to their task. (Maybe more so with the males?)

– 2. When do reuse, use copy/paste.

– 3. Process very iterative, debug/edit tightly interwoven.

– 4. Code impermanent.

– 5. Debugging challenges: less sophistication, multiple languages.

- 17 -

Improving EUPs’ Abilities in Software Development

• Teaching Software Engineering to EUPs (Umarji et al.)

– Bioinformatics developers don’t do software engineering (agrees with Segal’s findings).

– They do share. They don’t like to “hand off” outside their domain.

– Could benefit from education in QA, documentation, reuse.

- 18 -

Related Theories and Support

– Relates to Attention Investment (Blackwell)

• Cost/benefit/risk.

– Relates to Minimalist Learning Theory (Carroll/Rosson)

• Paradox of “Active User”.

– Strategies to support:

• Domain-specific languages/closeness of mapping.

• Surprise/Explain/Reward (Wilson/Burnett, …)

– Connectts Curiosity to Minimalist Learning to Attention Investment.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

- 19 -

Helping Tools Be More “Natural”

• “Natural” end-user software engineering (Myers et al.)

– Approaches/tools based on how end users think.

• How do they debug? (led to Whyline)

– Studies of people debugging: mostly they ask “why” and “why not”.

– Help inform Whyline debugging tool:

• for Alice (novices), for Word behavior (EUs),

• and now for Java (bringing what learned about EUPs back to professional devs.

- 20 -

Natural end-user software engr. (cont.)

• How Do UI Designers Design?

– They iterate on appearance (no problem) and behaviors (big problem).

• Complex, diverse behavior.

– They build software prototypes to communicate design decisions.

• Poorly supported by current tools.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

- 21 -

Natural end-user software engr. (cont.)

• Studies of professional developers too.

– Can reveal insights into emerging issues that will affect EUPs soon too.

– E.g., studies of API usability, program comprehension.

- 22 -

Conclusion: What we’ve learned

• End-user programmers

– Are not usually “baby” professional programmers, but do struggle with SE issues.

– And have unique problems, different motivations, different langs/tools, gender diffs relevant to EUSE…

• EUP studies provide critical info for tools.

– And also can reveal new insights that open new avenues for supporting professional devs too.

– And sometimes vice versa (apply with caution!)

- 23 -

Question

• What else do we know about end users that hasn’t come out yet?