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

Transcript

1. Bridging the Two Solitudes
   Tavish Armstrong
   http://tavi.sh/solitude
   

   View Slide

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
   

   View Slide

3. Conversations
   

   View Slide

4. “...an important aspect of Haskell's
   power lies in the compactness of the
   code we write.”
   

   View Slide

5. “Compared to working in
   popular traditional languages,
   when we develop in Haskell
   we often write much less code,”
   

   View Slide

6. “...in substantially less time,
   and with fewer bugs.”
   

   View Slide

7. Not everyone
   agrees!
   

   View Slide

8. A
   CHALLENGER
   “My impression is that the
   Haskell shrinking factor
   averages around four, but
   obviously it varies a lot.”
   

   View Slide

9. This isn't “someone is
   wrong on the internet”
   

   View Slide

10. This is “someone could be
    more right on the internet”
    

    View Slide

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.
    

    View Slide

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.”
    

    View Slide

13. Facts with no
    foundation
    

    View Slide

14. Scientists get this
    

    View Slide

15. Claims
    Evidence
    Citations
    

    View Slide

16. Claims
    Evidence
    Citations
    

    View Slide

17. Claims
    Evidence
    Citations
    

    View Slide

18. Can we do better?
    

    View Slide

19. We do benchmarks to test performance.
    We usability test our UIs.
    We use analytics on our websites.
    

    View Slide

20. Why don't we analyze ourselves?
    

    View Slide

21. Greg Wilson:
    What We Actually Know About Software
    Development, and Why We Believe It's True
    

    View Slide

22. View Slide

23. Making Software
    ●
    Offices: doors open or closed?
    ●
    Pair programming: yea or nay?
    ●
    Modern code review
    ●
    Failure prediction using organizational structure
    

    View Slide

24. View Slide

25. Some interesting papers
    (Read them!)
    

    View Slide

26. What can we learn about code review?
    

    View Slide

27. Rigby* and Bird, 2013 @ FSE
    “Convergent Contemporary Software Peer
    Review Practices”
    * my supervisor last summer
    

    View Slide

28. Patch Size
    

    View Slide

29. First Responses on Reviews
    

    View Slide

30. Number of Reviewers
    

    View Slide

31. Hindle et al, 2006
    

    View Slide

32. Academia is hard.
    Let's write code!
    

    View Slide

33. View Slide

34. View Slide

35. View Slide

36. View Slide

37. View Slide

38. View Slide

39. View Slide

40. Improvements
    An email:
    

    View Slide

41. Science
    ●
    People read it
    ●
    People reproduced it
    ●
    People fixed it
    ●
    People improved it
    

    View Slide

42. That was fun
    

    View Slide

43. Gousios, G., Pinzger, M., and van Deursen, A., 2013
    (ICSE)
    gousiosg/pullreqs
    gousios.gr/blog/on-github-pull-requests/
    

    View Slide

44. •
    80% of pull requests merged in < 3 days
    •
    while 30% merged < 1 hour.
    •
    70% of all pull requests are merged.
    

    View Slide

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.
    

    View Slide

46. How do people use git?
    

    View Slide

47. Tavish's Git Workflow
    

    View Slide

48. Julia's Git Workflow
    

    View Slide

49. Mozilla Baloo: Tracking contributor data
    

    View Slide

50. What time of day do most bugs get checked in?
    

    View Slide

51. View Slide

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
    

    View Slide

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
    

    View Slide