WSO2Con2024 - GitOps in Action: Navigating Application Deployment in the Plat...
Making Effective, Useful Software Development Tools
1. Making Effective, Useful
Software Development Tools
Gail C. Murphy
University of British Columbia
@gail_murphy
A more restrictive license has been
chosen given use of licensed images.
Image cannot be reused.
2. 2
A quick survey…
Intro
When you build software, do you mostly use…
command-line tools?
development environments?
something else?
3. 3
Problem: Your productivity (and the users of what
you produce) is limited because tools are more
oriented at computers than humans
Intro
Video cannot be reused.
4. 4
Example:
Sharing changes
based on [Bradley, Fritz, Holmes, ICSE 2018]
(a) Access issue tracker and check issue number
for current work item
(b) Open terminal and run tests against changed
code (e.g., npm run tests)
(c) Use terminal to commit code (e.g., git
commit -m ‘See issue 123’)
(d) Pull any external changes from remote
repository (git pull)
(e) Push the local change to the remote repository
(git push)
(f) Open the commit in the version control system
using GitHub web interface and open a pull
request
(g) Determine reviewers and assign them to pull
request
Intro
11. 11Whyline
[Ko & Myers, CHI 2004]
Identification of
Mismatch
Bridging
Theory
Assessment of
Effectiveness
Positive Case: Whyline
Debugging tools do not
support inquisitive nature of activity
Directly support hypothesizing:
why did and why didn’t questions
Comparative lab study shows
Whyline reduces debugging time by
a factor of ~8
14. 14Positive Case: Whyline
Assessment of
Effectiveness
Comparative lab study shows
Whyline reduces debugging time by
a factor of ~8
Image from: [Ko & Myers, CHI 2004]
15. 15Whyline
[Ko & Myers, CHI 2004]
Identification of
Mismatch
Bridging
Theory
Assessment of
Effectiveness
Positive Case: Whyline
Debugging tools do not
support inquisitive nature of activity
Directly support hypothesizing:
why did and why didn’t questions
Comparative lab study shows
Whyline reduces debugging time by
a factor of ~8
17. 17Mylyn
[Kersten & Murphy, FSE 2006]
Identification of
Mismatch
Bridging
Theory
Assessment of
Effectiveness
Positive Case: Mylyn
Development environments
cause developers information overload
and repetitive activities
Developers work on tasks and use
episodic memory to recall tasks
Field study shows that productivity
improves with Mylyn use
21. 21Positive Case: Mylyn
Assessment of
Effectiveness
Longitudinal field study (2005)
16 accepted users (99 started study)
13/16 user’s edit ratio improved
with Mylyn
Adoption (today)
2 million downloads per month
~ > 500K users daily
22. 22Mylyn
[Kersten & Murphy, FSE 2006]
Identification of
Mismatch
Bridging
Theory
Assessment of
Effectiveness
Positive Case: Mylyn
Development environments
cause developers information overload
and repetitive activities
Developers work on tasks and use
episodic memory to recall tasks
Field study shows that productivity
improves with Mylyn use
25. 25
Identification of
Mismatch
Negative Case:
Defect Prediction
Defects found in the field are costly to fix
Code reviews are costly to perform
Can developer time be focused on
parts of code most likely to contain
defects?
27. 27Negative Case:
Defect Prediction
Assessment of
Effectiveness
Google study: Embedded defect prediction
results into code review tool [Lewis et al, ICSE 2013]
“This file has been flagged as bug-prone … based
on the number of changeless it has been in with
‘bug’ attached…Please review carefully”
No effect on developers…
30. 30
“Even though the UNIX system
introduces a number of innovative
programs and techniques, no single
program or idea makes it work well.
Instead, what makes it effective is the
approach to programming, a
philosophy of using the computer. […]
at its heart is the idea that the power
of a system comes more from the
relationships among programs than
from the programs themselves.”
34. 34Tomorrow
Software development
tools are not amplifying
human intelligence
Study, definition and use
of context can improve
the flow of software
development work
https://www.slideshare.net/murphygc/the-need-for-context-in-software-engineering
35. 35Tomorrow
(a) Access issue tracker and check issue number
for current work item
(b) Open terminal and run tests against changed
code (e.g., npm run tests)
(c) Use terminal to commit code (e.g., git
commit -m ‘See issue 123’)
(d) Pull any external changes from remote
repository (git pull)
(e) Push the local change to the remote repository
(git push)
Example:
Sharing changes
based on [Bradley, Fritz, Holmes, ICSE 2018]
36. 36Tomorrow
(a) Access issue tracker and check issue number
for current work item
(b) Open terminal and run tests against changed
code (e.g., npm run tests)
(c) Use terminal to commit code (e.g., git
commit -m ‘See issue 123’)
(d) Pull any external changes from remote
repository (git pull)
(e) Push the local change to the remote repository
(git push)
Replace…
[Bradley, Fritz, Holmes, ICSE 2018]
37. 37Tomorrow
Human: Devy, I’m done
Devy: You have uncommitted changes.
Should I commit them?
Human: Ok
Devy: OK, I’m about to open a pull request,
should I assign Alice?
Human: OK
With Devy
[Bradley, Fritz, Holmes, ICSE 2018]
39. Thanks
to the funders of my research (NSERC in par8cular), my fantas8c
academic and industrial colleagues, post-doctoral fellows,
graduate and undergraduate students, to Mik Kersten and Robert
Elves (my co-founders at Tasktop Technologies) and to the
fantas8c team at Tasktop from whom I have learned so much.
Icons made by Freepik under a Crea8ve Commons BY 3.0 license
40. 40Summary
Let’s put the human
as the focus of the software
development tools
that we build
Image cannot be reused.