Bridging the Two Solitudes
Tavish Armstrong
http://tavi.sh/solitude
Slide 2
Slide 2 text
What is this talk about?
•
Let's use our data analysis tools to analyze our
FOSS projects
•
Let's make smarter decisions based on what we
learn
•
Teach others what we've learned and help them
reproduce our experiments
Slide 3
Slide 3 text
Conversations
Slide 4
Slide 4 text
“...an important aspect of Haskell's
power lies in the compactness of the
code we write.”
Slide 5
Slide 5 text
“Compared to working in
popular traditional languages,
when we develop in Haskell
we often write much less code,”
Slide 6
Slide 6 text
“...in substantially less time,
and with fewer bugs.”
Slide 7
Slide 7 text
Not everyone
agrees!
Slide 8
Slide 8 text
A
CHALLENGER
“My impression is that the
Haskell shrinking factor
averages around four, but
obviously it varies a lot.”
Slide 9
Slide 9 text
This isn't “someone is
wrong on the internet”
Slide 10
Slide 10 text
This is “someone could be
more right on the internet”
Slide 11
Slide 11 text
Python is more readable than other languages.
Unit testing helps us maintain quality.
We don't do unit testing; it takes too much time for
too little benefit.
Python is good for beginners.
C++ is better for beginners.
Happy programmers make better programmers.
Slide 12
Slide 12 text
Most patches don't get many reviewers.
You should keep your patches small.
Most code review is just nitpicking.
“Many eyeballs make all bugs shallow.”
Slide 13
Slide 13 text
Facts with no
foundation
Slide 14
Slide 14 text
Scientists get this
Slide 15
Slide 15 text
Claims
Evidence
Citations
Slide 16
Slide 16 text
Claims
Evidence
Citations
Slide 17
Slide 17 text
Claims
Evidence
Citations
Slide 18
Slide 18 text
Can we do better?
Slide 19
Slide 19 text
We do benchmarks to test performance.
We usability test our UIs.
We use analytics on our websites.
Slide 20
Slide 20 text
Why don't we analyze ourselves?
Slide 21
Slide 21 text
Greg Wilson:
What We Actually Know About Software
Development, and Why We Believe It's True
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
Making Software
●
Offices: doors open or closed?
●
Pair programming: yea or nay?
●
Modern code review
●
Failure prediction using organizational structure
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
Some interesting papers
(Read them!)
Slide 26
Slide 26 text
What can we learn about code review?
Slide 27
Slide 27 text
Rigby* and Bird, 2013 @ FSE
“Convergent Contemporary Software Peer
Review Practices”
* my supervisor last summer
Slide 28
Slide 28 text
Patch Size
Slide 29
Slide 29 text
First Responses on Reviews
Slide 30
Slide 30 text
Number of Reviewers
Slide 31
Slide 31 text
Hindle et al, 2006
Slide 32
Slide 32 text
Academia is hard.
Let's write code!
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
Improvements
An email:
Slide 41
Slide 41 text
Science
●
People read it
●
People reproduced it
●
People fixed it
●
People improved it
Slide 42
Slide 42 text
That was fun
Slide 43
Slide 43 text
Gousios, G., Pinzger, M., and van Deursen, A., 2013
(ICSE)
gousiosg/pullreqs
gousios.gr/blog/on-github-pull-requests/
Slide 44
Slide 44 text
•
80% of pull requests merged in < 3 days
•
while 30% merged < 1 hour.
•
70% of all pull requests are merged.
Slide 45
Slide 45 text
To merge or not to merge:
1. How active the area affect by the pull request
has been recently
2. The size of the project
3. The number of files changed by the pull
request.
Slide 46
Slide 46 text
How do people use git?
Slide 47
Slide 47 text
Tavish's Git Workflow
Slide 48
Slide 48 text
Julia's Git Workflow
Slide 49
Slide 49 text
Mozilla Baloo: Tracking contributor data
Slide 50
Slide 50 text
What time of day do most bugs get checked in?
Slide 51
Slide 51 text
No content
Slide 52
Slide 52 text
Tools
●
git2json: Tools to pull out data from VCS
history
●
gitcoach by Mike Hoye: “You modified file X?
Consider also modifying file Y.”
●
Idea: PR-lint: suggest improvements to pull
requests based on Gousios
Slide 53
Slide 53 text
●
Study how you write software
●
Teach your friends something cool
●
And back it up with evidence
●
Share what you learn with others
●
Build tools to make this easier
THANKS
http://tavi.sh/solitude
Send me emails!
tavisharmstrong@gmail.com
@tavarm