Software Engineering for Hackers: Bridging the Two Solitudes by Tavish Armstrong

Transcript

1. Bridging the Two Solitudes Tavish Armstrong http://tavi.sh/solitude
2. 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
3. Conversations
4. “...an important aspect of Haskell's power lies in the compactness of the code we write.”
5. “Compared to working in popular traditional languages, when we develop in Haskell we often write much less code,”
6. “...in substantially less time, and with fewer bugs.”
7. Not everyone agrees!
8. A CHALLENGER “My impression is that the Haskell shrinking factor averages around four, but obviously it varies a lot.”
9. This isn't “someone is wrong on the internet”
10. This is “someone could be more right on the internet”
11. 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.
12. 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.”
13. Facts with no foundation
14. Scientists get this
15. Claims Evidence Citations
16. Claims Evidence Citations
17. Claims Evidence Citations
18. Can we do better?
19. We do benchmarks to test performance. We usability test our UIs. We use analytics on our websites.
20. Why don't we analyze ourselves?
21. Greg Wilson: What We Actually Know About Software Development, and Why We Believe It's True
23. Making Software • Offices: doors open or closed? • Pair programming: yea or nay? • Modern code review • Failure prediction using organizational structure
25. Some interesting papers (Read them!)
26. What can we learn about code review?
27. Rigby* and Bird, 2013 @ FSE “Convergent Contemporary Software Peer Review Practices” * my supervisor last summer
28. Patch Size
29. First Responses on Reviews
30. Number of Reviewers
31. Hindle et al, 2006
32. Academia is hard. Let's write code!
40. Improvements An email:
41. Science • People read it • People reproduced it • People fixed it • People improved it
42. That was fun
43. Gousios, G., Pinzger, M., and van Deursen, A., 2013 (ICSE) gousiosg/pullreqs gousios.gr/blog/on-github-pull-requests/
44. • 80% of pull requests merged in < 3 days • while 30% merged < 1 hour. • 70% of all pull requests are merged.
45. 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.
46. How do people use git?
47. Tavish's Git Workflow
48. Julia's Git Workflow
49. Mozilla Baloo: Tracking contributor data
50. What time of day do most bugs get checked in?
52. 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
53. • 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