Slide 1

Slide 1 text

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! [email protected] @tavarm