1 institute for software research, international behold, we have signal

1

Institute for Software Research, International

BEHOLD, WE HAVE SIGNAL

2Institute for Software Research, International

Software Engineeringvs (???)

End User Software Engineering

Mary Shawwith Jim Herbsleb, Ipek Ozkaya

Carnegie Mellon University

http://www.cs.cmu.edu/~shaw/

3


CMU’s approach to SE education

Distinctive nature of engineering for software Software is design-intensive; manufacturing cost is

small Software is symbolic, abstract, more constrained by

complexity than by physical laws Software engineering rests on three foundations

Core computer science: technical conceptual foundation

Engineering knowledge: design and problem solving 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


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


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


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


So, what’s special about end users?

Professionals about something other than software Software is job #2 (or maybe #6) Less likely than prof programmers to take long view

Often develop software within applications, not in programming environments Aren’t aware of engineering issues (testing, evolution,

…) Don’t get much support from applications or peers Often do shallow programming – mimicry, not design

They are not all alike Different degrees of formal skill Different needs for variation on basic software themes Software fits organization in different ways

8


Categorizing End User Programmers

2012: 90 million people will user computers at work 55M spreadsheet/database, 13M “programmer”

What are they all doing? How do they think about SW? Listing apps doesn’t help us understand how to help them So find a better way to characterize them

What is “programming-like” behavior? Who does it? We have estimates of application usage But they confound subpopulations But they don’t distinguish sophistication of use But they don’t identify commonality across applications

Chris Scaffidi, Mary Shaw, Brad Myers

9


Categorizing End User Programmers

So study what abstractions use, and how End user tools provide some, not much,

abstraction Preliminary survey in Information Week

Asks about applications used – and features Do followup survey on specific population

(marketing) Next fall

Expect to find Use of abstractions such as function definition,

data representation, scripting, data flow/propagation …

Different levels of abstraction in use (e.g, Bloom’s)

10


Two Principles of End User SE Research

Not all end user developers are the same Here: professional end user developers, e.g, scientists

Use formalisms professionally coding per se not a problem Field studies: interviews of financial consultants & scientists

Professional end user developers (vs programmers) Goal is not code, but correct code matters 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


Two Principles of End User SE Research

Ideas from field studies for helping prof end users Don’t consider support that disrupts user context Consider software reuse & knowledge management

tools Obvious support mechanisms not effective

In-house software manual created but unmaintainable Improvements require resources and new attitudes

Consider popular ideas Standard development methods heavy; consider agile Component technology, but requirements must evolve Tailorable evolution may work if “product line” fits

12


Old Issues, New Eyes

End users create software without help from IT They can create immediate functionality But they don’t make provisions for sustaining the software

Inherent conflicts (well known) Domain knowledge vs technical knowledge Central control vs local autonomy (efficiency vs

availability) Evolution

More computing power in hands of more sophisticated users

Development is easier via spreadsheets (e.g.) and COTS

Michael M Pickard

13


Old Issues, New Eyes

New issues Offshore development reduces # of local technical

experts, creating more incentives for end user development

Falling enrollments reduces availability of tech personnel

IT curricula much more applied than CS curricula Questions

Will greater abstraction cause convergence of end user and professional developers?

With fewer tech developers, who will create and maintain the applications that support end user abstractions?

Where will COTS come from?

14


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 Many nontrivial faults Need implicit support for end user software

engineering Context: WYSIWYT testing with coverage display

tool Lack of progressive coverage localizes faults Like programmers, end users need testing support

But professional and end user developers are different

Joseph R Ruthruff and Margaret Burnett

15


Six Challenges in Supporting User Debugging

Challenges for debugging and other end-user activity Lack of software engineering knowledge

So provide tools that don’t require deep SE knowledge Need for interactive incremental tools, not modal tools

So match interaction style of tools to that of users Lack of organized (e.g. testing) infrastructure

So see what we can do without large prior knowledge bases End users don’t accurately evaluate program output

So make tools resilient to user errors Interactive techniques harder to evaluate (no batches)

So support users’ natural interaction style in debugging, too First use of new technique is risky

So provide short-term rewards

16


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


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


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


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


Reflection

Many of the same concerns arise in software engineering, but with different tools

This is not so much aboutSoftware Engineering vs End User Software

Engineering as about

Software Engineering vs Programming (for End Users)

1 institute for software research, international behold, we have signal

Documents

software v software

software research

software design

small v software

software product

software functionality

use software engineering

basic software themes