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

D21717ea76044d31115c573d368e6ff4?s=47 PyCon 2014
April 13, 2014
600

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

D21717ea76044d31115c573d368e6ff4?s=128

PyCon 2014

April 13, 2014
Tweet

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
  22. None
  23. Making Software • Offices: doors open or closed? • Pair

    programming: yea or nay? • Modern code review • Failure prediction using organizational structure
  24. None
  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!

  33. None
  34. None
  35. None
  36. None
  37. None
  38. None
  39. None
  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?

  51. None
  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