Three Lessons (of Many!) Learned

Phillip Gray

August 20, 2015

Two months, 216 commits, and 28 pull requests later, we’ve built a text adventure game in Python. And along the way, I’ve learned a few things both as a contributor and as a facilitator for the project. Below are three of the many lessons learned throughout the course of this project.

1. collaborative code != personal code

A few months ago, we decided to tackle a group project, and being the Python newbie that I am, I went hunting for a tutorial to serve as a scaffold for the project—I had never structured this big of a project before. So I mirrored the tutorial structure, wrote out the initial features list, and promptly left for vacation (poor timing!).

When I came back, there was a ton of great code written by group members, and it looked nothing like the code in my head or in the tutorial. I’m not sure if there are stages of processing a new codebase, but I certainly went through a few: panic, bewilderment, righteous refactoring anger, until I finally settled into acceptance and determination to jump in and build along with the group. I realized and was reminded that there are plenty of ways to attack a problem or process with code, and when you factor in the disparate creative minds of a group, it’s guaranteed that the code will be different than any one person could imagine or write.

2. projects_with clear and defined milestones > open-ended projects

After the initial feature list was discussed, we started building the game at the same time that we were brainstorming and adding more features to the game. This was a great way to evolve and construct the game by letting creativity and imagination guide the process. But if left unchecked, we would still be building and brainstorming: the open-ended nature of the game allows building and iterating to go on forever.

From a project management standpoint, it seems like defining clear goals and tasks to achieve milestones is a more efficient way to tackle a group project. There would still be opportunities to brainstorm and iterate between sprints and maintain a high level of creativity, without compromising productivity and focus.

3. if tests in code: return code_quality * 100

(see also, obey the testing goat!)

Early in the project, Jamal, one of the project contributors, suggested that we build the game using Test-Driven Development. A few of us had picked up Harry Percival’s book, TDD with Python, and this project seemed the perfect opportunity to try out TDD principles.

Result: before contributing to the project, I had never written a single test. And now all the project contributors have experience in both Python unittest and py.test. TDD afforded our code resiliency—the codebase has stood up to both multiple rounds of refactoring and the addition of many new features—and modularity.

Overall, working on and facilitating this project has been great. I’ve learned a ton about not only Python, but also git, GitHub, testing, code collaboration and more. I’m definitely looking forward to building the next project with the Python Thursday crew!