How development models affect the team by Maciej Fijałkowski

There has been a lot said about how to ensure correct quality control using tests, continuous integration, peer review etc. In this talk I would like to focus exclusively on my experience as an open source contributor with various projects. I've contributed extensively to projects I don't manage (like twisted, mercurial, cpython) and I've overseen contributions by others to projects like vmprof or PyPy. I would like to share my experience on how various methods (tests, reviews etc.) make me feel as a contributor and how easy it is to integrate changes based on that. I think the human factor of contributions is often too omitted from the process.

Transcript

1. How development models affect the team October 6, 2016 1 / 29
2. Who am I? Maciej Fijałkowski come from Poland, live in South Africa mostly PyPy project baroquesoftware - PyPy consultancy October 6, 2016 1 / 29
3. What am I going to talk about? there has lots been written about team & code quality there is not enough on "how it affects the team" October 6, 2016 2 / 29
4. Background open source development (pypy, vmprof, twisted, hg, cpython) volunteer/work for a decade lots of ideas about software engineering October 6, 2016 3 / 29
5. Open Source my main focus is open source some of this might apply to corporate teams everyone is a newcomer at some point October 6, 2016 4 / 29
6. Caveat this is not scientific research none of the stuff here means I’ve done proper studies October 6, 2016 5 / 29
7. But... all the projects are different it’s hard to do sound statistics in a team of 3 (un)voiced opinion matters October 6, 2016 6 / 29
8. What makes developers happy? very difficult question, depends... ability to feel empowered doing cool stuff October 6, 2016 7 / 29
9. Ideal scenario? everything is nicely tested deployment takes no time your turnaround time is <15s (test, deploy) ... but you can hack as much as you want October 6, 2016 8 / 29
10. Ideal scenario? everything is nicely tested deployment takes no time your turnaround time is <15s (test, deploy) ... but you can hack as much as you want October 6, 2016 8 / 29
11. Ideal system code reviews pair programming tests continuous everything short iteration times October 6, 2016 9 / 29
12. Ideal system code reviews pair programming tests continuous everything short iteration times October 6, 2016 9 / 29
13. Developer workflow find out what has to be done try to do it try it and see it fail debug/test repeat commit October 6, 2016 10 / 29
14. Developer workflow find out what has to be done try to do it try it... check facebook/HN ... wait for tests to complete debug/test repeat commit October 6, 2016 11 / 29
15. But not... find out what has to be done do it quickly wait 30minutes/2 weeks to test prevalent in the era of punchcards! October 6, 2016 12 / 29
16. But not... find out what has to be done do it quickly wait 30minutes/2 weeks to test prevalent in the era of punchcards! October 6, 2016 12 / 29
17. What can be optimized? all of the above! but let’s focus on the iteration ... and developer happiness October 6, 2016 13 / 29
18. Let’s get to details I’m going to talk about open source projects I contributed to ... or I helped to contribute to pypy, cpython, hg, twisted critique of processes, not projects October 6, 2016 14 / 29
19. Project quality all of the above (pypy, cpython, hg, twisted) are high quality they all have vastly different development process what improves/decreases team moral seems to be a good question? is your project welcoming? October 6, 2016 15 / 29
20. Power structures there is always a power structure lack of explicit one makes the power structure implicit October 6, 2016 16 / 29
21. Problems of distributed systems deadlock starvation (optional) fairness October 6, 2016 17 / 29
22. Problems of distributed development deadlock (A waits for B who waits for A) starvation (your patch never gets looked at) fairness (people can commit to core, but you cannot) October 6, 2016 18 / 29
23. Tests everyone has to write tests(or are some people excluded?) proving things about your code very useful makes it easier for developers to feel confident long test runs are frustrating October 6, 2016 19 / 29
24. Continuous integration makes you more confident about other platforms if not delayed can increase the testing time significantly October 6, 2016 20 / 29
25. Code reviews someone looks at the code you wrote very useful! can be potentially personal people tend to bikeshed smaller harmless patches more October 6, 2016 21 / 29
26. CPython very bugtracker based code reviews mandatory for newcomers (but not core) hard to get commit bit easy to wait months or forever for a review different responsibilities for different people tests less mandatory, but welcomed quick build time, slow tests October 6, 2016 22 / 29
27. Mercurial mailing list based hard to get commit bit code reviews mandatory relatively quick review process doctests, but required October 6, 2016 23 / 29
28. Twisted very test based very fast tests easy to get commit bit code reviews strict and mandatory tests strict and mandatory ... networking is hard October 6, 2016 24 / 29
29. PyPy very test based slow tests slow build time code reviews optional, post process delayed CI very easy to get a commit bit October 6, 2016 25 / 29
30. My personal view PyPy is a hard project - let’s simplify the contribution process having a swiss on the team helps a lot reducing test times/build times would help a lot October 6, 2016 26 / 29
31. Is this contribution relevant? if we think this is a net positive - we’ll merge it for code that noone touches - let’s merge it instead October 6, 2016 27 / 29
32. Summary the iteration time is crucial the frustration can come from both humans and robots robots are harder to hate (they mean well) October 6, 2016 28 / 29
33. Q&A Thanks! Questions? pypy.org/baroquesoftware.com talk to me! October 6, 2016 29 / 29