How to promote shared code-ownership in teams with fast turnover?

Question

Im involved with an academic software project in which 2 half-time PhD students manage 4-8 students. Turnover in this project is high, because students join for their 10 weeks Bachelors thesis or six month Masters thesis, then graduate and are gone forever.

Each thesis usually involves the development of a new feature and while we stress the responsibilities for fixing bugs in the work of other students, we have slowly reached the point where shared code-ownership does not exist anymore. People rarely fix issues in other peoples code, but leave their new features in a state, which would need cleaning desperately.

So the question:

• How do you encourage shared code-ownership if people are only involved in a project for a short time?

P.S.: Except for failing the students, we have little leverage.

Answer 1

My recommendations, short of failing them is deny them commit access. Do code reviews. If their code doesn't cut it, then don't let them commit it(and therefore, it basically doesn't exist as part of their thesis until they fix it)

To get them to fix other peoples bugs, have a week or something where commit access is denied to everyone unless its a bug fix and tell everyone that they must test everything in the program. If they refuse to help test, then deny them commit access permanently.

Believe it or not, having to submit patches rather than having commit access is enough of an annoyance that it will at least help the code ownership problem.

Answer 2

Basically, you can't. Having someone take ownership of something involves them becoming part of a community and having a stake in the final outcome of the project. Since your students are there for a very limited time, they have little incentive to join the community. Since they'll be leaving forever shortly, they are unlikely to have a stake in the final outcome unless they plan to go into a field where your project may be a useful tool for them.

So, since your current arrangement cannot achieve the results you wish, you are going to have to think deeply about changing the arrangement. You need to ask a lot of questions like: Why do these students do a 10-week or 6-month stint with you? What are they supposed to get out of it? What are you? Are these even compatible goals?

Answer 3

A wise professor once said, "Students do what you inspect, not what you expect." You need to make shared code ownership a part of the students' grade determination.

Answer 4

Make someone's thesis be related to "identifying and fixing bugs"

Make someone else's be "develop a comprehensive test suite"

Do you not have the ability to assign grades based on code quality? Or are your projects strictly pass/fail?

Answer 5

Increase test cases and incorporate code coverage as a requirement of a code check in

Answer 6

It seems like you may not want to have severe punishment as your first line; after all, you presumably need to be able to keep recruiting students. Preferably good ones. So: incentives? Even stupid ones? Like scoring points for the number of existing bugs fixed, or for doing the stuff Brian suggests? A reputation score of some sort? We know programmers are never motivated to spend time they never would otherwise by arbitrary point systems, right? Oh, wait....